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Abstract —The severity of amplification attacks has 
grown in recent years with recent attacks involving several 
hundreds of Ghps attack volume. In this paper, we survey 
the threat of amplification attacks and compare a wide 
selection of different proposals for preventing, detecting, 
and filtering amplification attack traffic. Since source IP 
spoofing plays an important part in almost all of the 
amplification attacks surveyed, we also survey state-of- 
the-art of spoofing defenses as well as approaches to trace 
spoofing sources. This work acts as an introduction into 
many different types of amplification attacks and source 
IP address spoofing. By combining previous works into a 
single comprehensive discussion we hope to prevent redun¬ 
dant work and encourage others to find practical solutions 
for defending against future amplification attacks. 


I. Introduction 


Denial of Service (DoS) attacks against networks at¬ 
tempt to make a system or an entire network unavailable 
for its intended purpose Q. In some cases DoS attacks 
cause a complete loss of Internet connectivity for the 
victim Q. The motivation for DoS attacks can be finan¬ 
cial 0, 0, political 0, ideological Q, reputation Q, 
0- to test new techniques and prepare for larger attacks, 
or purely for disruptive purposes 0. 

A general overview of DoS attacks and defense strate¬ 
gies can already be found in the surveys by Mirkovic 
and Reiher Q, Douligeris and Mitrokotsa 110|, and 
more recently Zargar et al. m Instead, this paper 
focuses on a particular type of DoS attack called an 
amplification attack (also called Distributed Reflective 
Denial of Service (DRDoS) attacks | [T^ , fT^ ) where the 
attacker seeks to maximise the volume of attack traffic 
sent to the victim whilst minimising the volume of traffic 

We will not 


they send to trigger the attack |14|- 
discuss other low traffic volume and high impact DoS 


attacks, e.g., Slowloris | [2T| or TCP SYN floods 
unless their defenses are also applicable to amplification 
attacks. Generally, the adversary in amplification attacks 
targets vulnerabilities in Internet protocols and services 
to amplify tbe amount of attack traffic. The ease of per¬ 
forming amplification attacks and greater understanding 
of their effect has led to an increase of attacks in recent 
years. This is supported, e.g., by the OpenDNS Security 
Eab that saw over 5,000 different amplification attacks 
every hour in 2014 [23 1, and by Rossow’s survey of 
amplification vulnerabilities |13|. 

Tbe most prominent form of amplification attack seen 
in recent years abuses the lack of endpoint verification 
in the Internet Protocol (IP) in order to trick third-party 
servers into sending large amounts of data to victims. 
That is, attackers spoof source IP addresses |24| to hide 
their identity and cause third-parties to send data to the 
victim as identified by the source address field of the IP 
packet. This is also sometimes called reflection because 
attackers “reflect” attack traffic off of benign services. 

As well as reflection, attackers sometimes strive to 
maximize the attack bandwidth sent to the victim by 
using amplification. Eor example, many UDP-based pro¬ 
tocols (such as DNS or NTP) that have a higher response 
payload size than the requests can be abused to amplify 
the reflected attack traffic. Consider DNS, while DNS 
lookup requests are typically rather small, the responses 
may be significantly larger, e.g., due to verbose informa¬ 
tion such as DNSSEC records. 

By combining reflection and amplification attackers 
can generate attack traffic volumes which are signifi¬ 
cantly higher than their uplink bandwidth 0, Q, Q, 
p5| . Eurthermore, not only single hosts may be affected 
by such attacks. Entire networks may struggle to cope 
with the extra bandwidth and processing demands |25|. 
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from the past and discuss amplification attacks in great 
detail. We then describe methods to prevent amplification 
attacks in Section III Then special attention is paid to 
preventing reflection and IP spoofing in Secfion IV We 
finish fhe discussion ahouf fhe solufion space in Sec¬ 
fion |V] hy presenting approaches fo defecf and filfer am¬ 


plification affacks. Finally, we conclude in Secfion VI 


II. Amplification Attacks 

This secfion provides a defailed infroducfion info fhe 
differenf fechniques for amplifying affack fraffic. We sfarf 
hy giving a brief faxonomy and fimeline of differenf 
fypes of amplificaifon affacks, and fhen we end fhe 
secfion by describing fhe fechniques used in more defail. 


A. Taxonomy and Historical Background 
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Fig. I. Categorisation of the amplification DDoS literature. 


Defending against this form of amplification attack 
is challenging for network operators. Firstly, the attack 
traffic blends in benign communication and may be 
hard to distinguish from legitimate traffic. Secondly, 
the attack packets received by victims are reflected by 
many distributed benign third-parties such as open DNS 
resolvers, effectively hiding the attacker’s identity |26|. 


In this survey paper, we systematically structure ex¬ 
isting research on amplification attacks to assist future 
research in this direction. To the best of our knowledge, 
we are the first to categorize an research area that spans 
almost 200 publications and has become an important 
problem both in academia and practice. To this end, we 
first compare various definitions and types of amplifica¬ 
tion attacks. With this foundation, we then systematize 
preventive countermeasures, and particularly look at the 
problem of (identifying and mitigating) IP spoofing. We 
complete our survey with works that proposed reactive 
countermeasures to defend against ongoing amplification 
attacks. Our main contribution is thus a comprehensive 
survey of existing literature that until now was scattered. 


The rest of this paper is organised as shown in 
Figure [T] In Section we present prominent incidents 


There are many ways of amplifying the volume of 
attack traffic in DoS attacks. In this paper we give 
special focus to amplification attacks which use UDP 
based amplifying protocols and reflection. However, it is 
important to be able to distinguist between the different 
types of amplificaiton attacks. 

1) DNS Servers as Amplifiers: In 1999, 
AusCERT 1271 warned about amplification attacks 
where attackers trick DNS servers into sending large 
amounts of data to spoofed IP addresses p^ . In 2000, 
the CIAC warned of Distributed Denial of Service 
(DDoS) attacks where attackers can send spoofed IP 
packets from many different locations [281. 

Today, DNS is widely used in amplification attacks 
because a 60 byte request from an attacker can easily 
generate a 512 byte response Q, |[^, 114|. Furthermore, 
DNS servers which support Extension mechanisms for 
DNS (EDNS) |29| can generate responses which are 


nearly 100 times larger than requests 113|. Some at¬ 
tackers even ensure large responses by creating domains 
specifically to use in amplification attacks | |2^ . 

Any public DNS server which is configured to respond 
to requests for hosts outside of their domain can be used 
in amplification attacks. DNS servers that are configured 
to respond to all such requests are known as open DNS 
resolvers. According to the Open DNS Resolver Project 
approximately 25 million open DNS resolvers currently 
“pose a significant threat” to the Internet |2^ . It is also 
not difficult to find enough open DNS resolvers to use 
in amplification attacks. Rossow showed that it currently 
only takes 90 seconds to acquire a list of 100,000 open 
DNS resolvers |[T3|. 
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Fig. 2. Timeline of amplification attacks and related events. 


2) Other UDP Based Services: The DNS based 
amplification attacks just described use source IP ad¬ 
dress spoofing to trick third-parties into attacking a 
victim | [2^ . 

Source IP address spoofing also makes it very difficult 
for the victim to track attacker because all attack traffic 
they receive will come from third-parties. UDP is also 
used by attackers as the transport layer protocol because 
it is stateless and has no built in mechanism to verifying 
the source IP address of packets. 

Recently, another UDP based protocol (SSDP) has 
been used with source IP address spoofing in amplifi¬ 
cation attacks. The United States Computer Emergency 
Readiness Team (US-CERT) first issued a warning about 


SSDP in January 2014 130|, and in October 2014 it was 


used to generate 54Gbps of traffic in a single attack |311. 

Other well documented DoS attacks that used UDP 
and source IP address spoofing are the MIT SNMP 
based attack | |32l |, and the CloudElare attack which 
reached a peak of nearly 400Gbps using 4,529 NTP 
servers | |25l |. The huge volume of traffic generated in 
the CloudElare attack was caused by a command in NTP 
called “monlist”, which returns a list of the previous 600 
IP addresses to access the server. Monlist does not affect 
the core functionality of NTP and should be disabled by 


network. These attacks are known as Smurf attacks | [35| , 
| [36l , and in Smurf attacks the routers which broadcast 
the requests act as amplifiers because they increase the 
volume of attack traffic. 

End hosts which respond to requests after they are 


broadcast may be amplifiers as well. Eor example, in 
Eraggle attacks an attacker may send CharGen requests 
to the broadcast address of many networks at the same 
time 0. End hosts which receive CharGen requests 
may respond with much more data than they receive, 
thus the end hosts in Eraggle attacks are amplifiers as 
well as the routers which broadcast the request. 

4) Fork Loops: There is also another category of 
amplification attacks which we have not yet covered. 


In 2009 Shankesi et al. |38| described an amplification 
attack as being where ’’the number of messages on the 
network can amplify to essentially an arbitrary large 
number” | |T6| . It is important to note however that this 
definition doesn’t take into account the size difference 
between request and response packets, which is an 
important factor in the UDP based amplification attacks 
we have already mentioned. 

The amplification attacks described by Shankesi et 
al. are caused by “fork loops” which are used to at¬ 


upgrading to version 4.2.7 and above |33|. 

3) Smurf and Fraggle Attacks: As well as misusing 
UDP based services, there are many other ways of 
amplifying attack traffic volume. Eor example, prior 
to 1998 attackers were sending ICMP requests to the 
broadcast address of networks whilst spoofing the source 
IP address of victims. The routers receiving the ICMP 
requests broadcast the requests to all of the hosts on their 


tack VoIP networks running SIP |38|. Pork loops are 
situations where requests are sent between SIP proxies 
indefinitely and at least one extra request is generated 
every iteration (g. Using this type of amplification 
attack it is possible to cause 2 SIP proxies to exchange 
up to 2™ duplicate requests consuming their resources 
and preventing them from responding to legitimate re¬ 


quests |38|. 


B. Responding to a Growing Threat 

Today, Smurf, Eraggle, and Pork Poop attacks have 
largely been countered by better network configuration 
and patches to SIP respectively. However, attacks involv¬ 
ing reflection and UDP based amplification are growing 
in number. 

Akamai detected 9 DoS attacks involving NTP, Char¬ 
Gen, and SSDP which peaked over 100 Gbps in the last 
3 months of 2014. This is three times more than in the 


same period in 2013 |34|. 
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TABLE I 

Recent large scale amplification attacks and their properties 


Reference Year Amplification Protocol Peak Traffic Attacker 


MIT 1321 


2013 SNMP 


Unknown Unknown 


GreenNet 


2013 DNS 


100 Gbps Unknown 


Prolexic 


0 


2013 DNS 


167Gbps Unknown 


Spamhaus 


81 2013 DNS 


300Gbps Cyberbunk 


PhantomLOrd 


17 


2013 


NTP 


A hacker group named 
lOOGbps DERP claimed respon¬ 

sibility on Twitter. 


CloudFlare 

25 

2014 

NTP 

400Gbps 

Unknown 

Akamai 

31 


2014 

SSDP 

54Gbps 

Unknown 


Description 

Spoofed requests were directed to 
SNMP enabled devices on the MIT net¬ 
work which attacked devices outside 
the network. 

Attackers brought down GreenNet, a 
hosting company who’s customers in¬ 
cluding Privacy International and Zim¬ 
babwe Human Rights Eorum. 

The attack targeted a real-time financial 
exchange platform. 

Over 30,000 DNS servers were in¬ 
volved in the amplification attack. At¬ 
tackers also used SYN floods and pre¬ 
fix hijacking to disrupt the Internet 
connectivity of Spamhaus and Project 
Honeypot. 

Attackers targeted game servers and 
streaming sites. Attacks against the 
games industry are becoming increas¬ 
ingly popular |34[ . 

Latency increased all over Europe fol¬ 
lowing attack using 4,529 NTP servers. 
French hosting firm OVH also claimed 
to have seen an attack over 350Gbps at 
the same time. 

Many of the devices used in this attack 
were home-based UPnP devices. 


Figure]^ and Table [^illustrate that the bandwidth used 
in amplification attacks is also growing. In March 2013 
an amplification attack was launched against Spamhaus 
Q. The DNS based attack reached an estimated peak 
of about 300Gbps and was the biggest DoS attack ever 
recorded |39|. Nearly a year later and an even bigger 
attack reportedly reached a peak of 400Gbps by using 
NTP 


The attack traffic generafed during fhe Spamhaus 
affack came from over 30,000 differenf DNS servers. 
In order to guard against this and future attacks, they 
deployed anycast routing and a distributed Content 
Delivery Network (CDN) Anycast involves BGP 
routers simultaneously advertising the same destination 
IP address so that attack traffic can be absorbed by 
many different data centers. However, relying on anycast 
and CDNs may be a short term solution, and it can 
only prevent amplification attacks when amplifiers and 
anycasf roufes are evenly disfribufed around fhe Infernef. 


The CloudFlare attack came 1 month after a “monlist” 


warning issued by US-CERT p3| , and during a 13- 
week period in which Kiihrer et al. reported a 92% drop 
in the number of vulnerable NTP servers | [T^ . As a 
consequence we may need to reevaluate how we respond 
to threats as they are discovered. For example, alerting 
system administrators about protocol vulnerabilities may 
prompt attackers to abuse the identified amplification 
vectors. 


C. Problem Description 

In this section we will provide high level descriptions 
of the attacks and concepts seen so far. We will start by 
discussing the amplification factor of different attacks 
and go on to describe the building blocks of the most 
common amplification attacks. 

1) Amplification Factor: The amplification factor of 
an attack {X{P)) for a protocol (P) is the ratio of the 
total number of bytes in the amplified fraffic (explicitly 
including headers, padding and payloads of all protocols 
involved, such as Ethernet, IP, UDP or the application- 
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level protocol) and the number of bytes sent by the 
attacker (same calculation), as shown in Equation [T] 


XiP) = 


number of response bytes{P) 
number of request bytes (P) 


( 1 ) 


Our definition is slightly different from the one used 
in (H). as we explicitly include all lower-level proto¬ 
cols, whereas Rossow focused on the number of UDP 
payload bytes. Still, the amplification factors provided 


by Rossow |13| offer a convenient way of comparing 
protocols and can help with prioritization. For example, 
Rossow found that NTP had the highest amplification 
factor all of the protocols he tested. He found that if 
attacks carefully select the NTP servers to maximize 
their attack they can achieve an amplification factor 
of 4670, which when compared to 64 for open DNS 
resolvers shows us how urgent it is to update existing 
NTP infrastructure. 

2) Reflection: Many of the amplification attacks in 
the past were possible because the attacker can spoof 
the address of the victim causing traffic to be “reflected” 


by third-party servers, e.g., by open DNS resolvers [401 
(see Section II-A[ ). Figure shows a reflection attack 
where an attacker (M) changes the source address in 
the request it sends to the reflector (R). Not knowing 
that the source address was spoofed, the reflector sends 
its response to the final destination {D, i.e., the victim). 

The key advantages of reflection attacks for the at¬ 
tacker are: (a) attackers hide their identity from D be¬ 
cause all traffic received by D comes from third-parties; 

(b) attackers can trigger attacks coming from different 
geographic or topological regions of the Internet; and 

(c) attackers do not receive responses and therefore do 
not risk using up their available download bandwidth. 



Fig. 3. Reflection attack. An attacker (M) sends a spoofed request 
to a reflector (R) which responds to the final destination (D). 


One example of a DoS attack which uses reflection is a 
TCP SYN/ACK attack, where an attacker sends spoofed 


SYN requests to a reflector so that the reflector sends 
SYN/ACK packets to the victim [411. 

As well as the final destination as indicated by the 
spoofed source IP address, it is also possible for reflec¬ 
tors and those that use them legitimately to be victims 
of reflection attacks. For example, in SYN flooding 
attacks p2l-||47l, the attacker floods a reflector with 
spoofed SYN requests and changes the source IP address 
of packets so they do not receive replies. The aim of 
SYN flooding attacks is not to attack the final destination 
indicated by the spoofed IP address, but to consume 
enough resources at the reflector to make it unresponsive 
to legitimate traffic. The adversary can also attack multi¬ 
homed networks using reflectors. For example, if the 
reflector is connected to the Internet by at least two 
uplinks, and the link between the reflector and the 
final destination offers significantly lower bandwidth 
compared to the link between the attacker and reflector. 
Then by carefully selecting a spoofed source address 
which is reachable via the low bandwidth connection, 
the attacker can implement a DoS attack on this link. 

It is worth mentioning again, however, that not all 
of the amplification attacks described in this paper use 
reflection, e.g., fork loop based attacks do not |16|. 

3) Ampliflcation: A key factor in amplification at¬ 
tacks is the ability of attackers to trigger responses which 
are significantly larger than the requests, either in terms 
of bytes or number of packets. Figure describes the 
basic scenario without reflection where an attacker sends 
a request to an amplifier {A) which responds with a 
higher volume of data than it receives. In this scenario 
the amplifier, or the network between the attacker and 
the amplifier, are the victim because they cannot cope 
with the amplified traffic. The main advantage of such 
an attack is twofold. First, the adversary saves resources 
with respect to its network uplink. This is important in 
case of mobile scenarios. Second, discovering the trigger 
of the attack is more challenging. In contrast to high 
volume flooding attacks, amplification triggers are hardly 
visible on frequently used uplinks, which complicates 
early detection. 

It is worth noting that the attacker model implies that 
the attacker is either capable to handle potential response 
traffic or that the attacker will not receive the response 
data. The latter follows directly in case of a successful 
attack but can also be achieved by address renewals at 
the attacker side. 

Pure amplification attacks will be of increased impor¬ 
tance with the upcoming deployment of the Internet of 
Things (loT). loT networks are characterized by con- 


5 











strained devices with limited network capacity, typically 
connected via border routers to the Internet. Congesting 
the path from some of the loT devices to the gateway 
may lead to disconnecting the complete loT domain. 


Request 



Fig. 4. Simple amplification attack. An attacker (M) sends a request 
to an amplifier (A) which responds with more data than it received. 
The response line is dashed in this instance to indicate that the 
attacker may not receive the response. 

4) Reflection and Ampliflcation Together: All of the 
amplification attacks seen in Table combine reflection 
and amplification, a high level overview of these attacks 
is given in Figure In this model an attacker (M) 
sends requests using the amplification protocol (P) to 
the amplifiers {A) but also uses reflection so that the 
amplifiers respond to the victim {V). 



Fig. 5. An attacker (M) sends spoofed requests to many amplifiers 
(A) causing amplified responses to be sent to the victim {V). 


The volume of attack traffic which can be sent to V de¬ 
pends on the accumulated available bandwidth between 
M and Ai...An, the accumulated available bandwidth 
between Ai...An and V, and the amplification factor of 
P. Depending on the success of the attack, the volume 
of traffic sent to the victim can result in a complete loss 
of connectivity for the victim and their network. 

5) Ampliflcation Attacks Using a Botnet: Most am¬ 
plification attacks are launched from single origins [481 
and just appear to be distributed due to the large set 
of amplifiers. However, a single attacker may not have 


sufficient uplink bandwidth to send requests to many 
amplifiers at the same time. Attackers can target more 
amplifiers, and further obscure the origin of attacks, by 
means of a botnet i fTTl , | |49l . 

The owners of hot-infected systems are unaware that 
their machines are being used in DDoS attacks. Alter¬ 
natively, in crowd-sourced DDoS botnets, participants 
willingly install attacking software on their machines, 
e.g., the Low Orbit Ion Cannon (LOIC) software ISOj . 
Such volunteer botnets were used in Operation Payback 
to attack global companies, such as MasterCard, Visa, 
and PayPal Q. 

Figure shows one model of an amplification attack 
using a botnet. In this example the attacker uses a 
controller (C) to send instructions to the botnet (P). The 
hots then send spoofed requests to amplifiers at similar 
times, such that the bandwidth of Bi...Bn accumulates. 


Requests Responses 



Fig. 6. An attacker uses a controller (C) to instruct a botnet {B) to 
simultaneously send spoofed requests to many amplifiers (A), causing 
amplified responses to be sent to the victim (V). 

6) Fraggle and Smurf Attacks: Fraggle and Smurf 
also use reflection and amplification, but their attacks 
look slightly different from the model in Figures]^ and 
Figure [7] shows a Smurf attack where M sends a request 
to the broadcast address of network {N), A acts as the 
amplifier by duplicating the request, and the reflectors 
{R) send responses to the victim V. Fraggle attacks are 
similar to Smurf attacks but the requests are amplified 
even further by the end hosts that receive them. 

7) Fork Loops: Fork loops are different to the reflec¬ 
tion and amplification attacks because they rely on mes¬ 
sages recursively being sent between SIP proxies fT^ . 
Yet fork loops have also been referred to as amplification 
attacks because they provide a way for an attacker to 
amplify the number of requests they send to SIP proxies. 
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D. Discussion 



Fig. 7. Smurf attack. An attacker (M) sends a spoofed request to 
the broadcast address of network (N). The amplifier (A) broadcasts 
the request to many reflectors {R) which respond to the victim (V). 


Figure shows one example of what can happen when 
two SIP proxies (Li and L 2 ) are not configured correctly 
and do not detect loops. It depicts the scenario descrihed 
in | [3^ where a request for the user a@Li is sent to 
the proxy Li. In this example, Li has two options for 
reaching a@Li which are both located at L 2 . This causes 
Li to fork the request and send two copies to a@L 2 and 
6 @L 2 which also both fork the request to a@Li and 
b@Li. The scenario is caused by misconfiguration and 
can potentially result in 2^ duplicate requests created 
where n is the number of iterations. 



Fig. 8. Fork Loops. In this example taken from |38| a single request 
spawns 2" duplicates where n is the number of iterations. 


In this section we have described many different types 
of amplification attacks. It is clear from our descriptions 
that the attacks seen in Table [I] are very different from 
Fraggle and Fork Loop attacks. 

Therefore, this survey will focus on the types of 
amplification attacks seen in Table and as described in 
Figures and The major advantages of amplification 
attacks from an adversarial point of view are: 

• Attack traffic can be amplified beyond fhe affacker’s 
upload bandwidfh. 

• The attacker remains anonymous by using reflection 
(IP address spoofing). 

• The aftack fraffic af reflecfors and amplifiers can be 
very difficult to distinguish from legitimate traffic. 

• The attack complexity is rather low and it is thus 
relatively straightforward to get started with ampli¬ 
fication attacks even for the wide audience. 


III. Preventing Amplification Attack 


In this section, we will describe preventative measures 
for the amplification attacks. For example, we discuss 
preventative measures which amplifiers can use before 
responding fo requesfs (e.g. response rafe limifing), and 
more radical approaches such as alternafive contenf 


delivery systems |51|. We will discuss non-preventive 
(i.e., reactive) countermeasures, such as detection and 
filtering, in Section [V| 

A. Alternative Internet Architectures 

Alternative Internet architectures such as Capability 
Based Architectures (CBA) |[5^, |[5^ or Content-Centric 


Networking (CCN) | |5T| may remove existing DoS vec¬ 
tors. For example, in CBA, senders must first obtain 
“permission to send” from the destination before sending 
packets. Anderson et al. | [52t proposed that verification 
points around the network ensure that the source has 
permission to send data to the destination. To obtain 
permission, Anderson et al. suggested that the source 
uses Request-To-Send (RTS) packets, which are routed 
between RTS servers to ensure the victim is not flooded. 

However, fhe problem wifh fhe CBA sysfem from 
Anderson et al. 


and the more recent TVA p^ , 
is that every packet must include some kind of extra 
“capability” information. Maintaining, exchanging, and 
checking capabilities creates a lot of extra overhead 
for networks, and the increased packet size may also 
increase fragmentation. 
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CCN will remove the possibility of DNS based am¬ 
plification attacks simply because DNS is no longer re¬ 
quired. In CCN, ISPs can deploy content routers to cache 
data which many users request. However, CCN uses the 
request/response paradigm in the form of “Interest” and 
“Data” packets, and it is currently unknown how resilient 
CCN would be to amplification attacks or new forms of 
DoS attacks. 


B. Lowering Amplification Factors 


Alternative, to remain compatible with the current 
Internet design, is fixing the protocols that are vulnerable 
to amplification. One such approach is to lower the 
amplification factors, e.g., by increasing the size of the 
requests in vulnerable protocols. This would reduce the 
amplification factor, but also increase the traffic across 
the Internet, which is not desirable. Moreover, it is 
not reasonable to suggest that all protocols should be 
amplification free. For example, it is quite reasonable to 
expect that request packets for large files are smaller or 
fewer than the response. 

A more practical approach for lowering the amplifica¬ 
tion factors may be to disable the redundant services that 
amplifiers offer. For example, Rossow showed that the 
Network Time Protocol (NTP) has the highest amplifi¬ 


cation factor out of the 14 UDP protocols he tested 1131. 
Kuhrer et al. achieved a reduction of the amplification 
factor of NTP by disabling the NTP services with the 


highest request/response factors |19|. Since the services 
with the highest request/response factors do not affect 
the core capabilities of NTP, these extra services can be 
disabled while still enabling time synchronization. 

Next to NTP, many other protocols (e.g. DNS, Char- 
Gen, SNMP) can be used for amplification attacks. 
Some DNS providers have recently started deprecating 
the DNS ANY request in response to the growing 
threat of amplification attacks. One provider, CloudFlare, 
now responds with the RCODE 4 “Not Implemented’^ 
However, identifying and disabling services with high 
request/response factors takes time, and may result in 
the loss of functionality for benign applications. 

One technique to reveal protocols which suffer from 
amplification attacks due to misconfiguration or bad 
design can be model checking fT^ . By modeling the 
protocol using rewriting logic | |5^ , a set of system 
states can be generated and checked for amplification 
by comparing the cost of servicing requests against a 


https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ 


predefined thresholcQ This approach can be used to 
detect flaws in protocols where the amplification factor 
at a single point might not seem significantly high, and 
it has been used to describe forking loops in SIP fT^. 


C. Reducing the Number of Amplifiers 

Many amplifiers were used in the larger amplification 
attacks. For example, over 30,000 separate open DNS 
resolvers were used in the Spamhaus attack (See Table [I]). 
A number of projects listed in Section VI are attempting 


to bring misconfigured amplifiers to the attention of 
system administrators so that they can be patched or 
configured correctly. However, this relies on widespread 
cooperation between administrators who may not have 
the knowledge or the resources to update their servers. 

Another interesting point to make here is does the 
Internet need so many public services such as DNS 
servers? Perhaps more cooperation between network 
providers can lower the impact of amplification attacks 
by lowering the number of amplifiers required to operate 
the Internet. 


D. Response Rate Limiting 

Moreover, amplifiers could also be configured to re¬ 
spond to a limited number of request from each IP or 
network address within a given time frame. For example, 
support for response rate limiting is easily applied to 
DNS when using newer versions of BIND. However, 
rate response rate limiting protects against abuse of a 
single amplifier and an attacker may simply choose to 
use multiple amplifiers at a low request rate. It only 
takes an attacker a short amount of time to look for 
a sufficient number of different amplifiers (less than a 
minute in some case Gl). 


E. Sessions for UDP 

Many amplification attacks rely on stateless commu¬ 
nication via the UDP protocol in order to send large 
amounts of data to spoofed IP addresses. Those amplifi¬ 
cation attacks are made more difficult if UDP-based pro¬ 
tocols required sessions to be opened (similar to the TCP 
three-way handshake) before large amounts of response 
data can be transmitted. To counter this, one can include 
session information in UDP packets. For example, clients 
using the Steam query protocol have to request a 4- 
byte challenge before they can request large amounts 
of information about a game server |55|. The client 
has to append the challenge response to future requests. 


^The cost in |l6) is the number of duplicate packets generated by 
SIP proxies 






However, attackers may be able to use responses from 
session initialisation exchanges for amplification attacks 
so long as they can open new sessions for the same 
victim with many amplifiers, and can also eavesdrop on 
fhe vicfims Infernef Iraffic fo see responses. 

A downside fo session hardening UDP profocols is 
fhaf if increases fhe packef sizes (and, depending on 
fhe implemenfafion, requires addifional packefs for a 
handshake), which conflicfs in particular in resource- 
consfrainf and real-lime conlexls. If may also add lalency 
fo fhe initial requesl fo open a sessions. The mosl 
challenging aspecf of session hardening existing UDP- 
based services is compalibilily wifh exisling clienls. In 
order fo prevenl amplification attacks session support 
would have fo be universal, and upgrading may cause 
problems wifh legacy sysfems. 


F. Differentiating Bots From Humans 

Also Complelely Aulomaled Public Turing lesls fo fell 
Compulers and Humans Aparl (CAPTCHAs) 1561 would 
prevenl attackers from using certain services in DoS 
attacks. While successful fo defend againsl applicalion- 
level DoS attacks, CAPTCHAs are nol successfully 
used in practice againsl amplification attacks, and we 
name fhem for complefeness only. Consider, for example, 
DNS, where lookups are oflen caused by a user visiling a 
websile. If such DNS requesls required lhat a user com- 
plefes a CAPTCHA, fhen if would be harder for attackers 
fo use open DNS resolvers for attacks. However, Ihis 
may delay a users access fo informalion and complicate 
legilimale aulomaled services which use DNS. Wifh Ihis 
in mind, Oikonomou |57| attempted fo model human 
behavior so fhaf servers can aufomalically dislinguish 
belween requesls from bots and requests from humans. 

There is another problem with only replying to re¬ 
quests from humans, and that is that many legitimate 
automated processes need to make requests for infor¬ 
mation over the Internet. These processes are prevented 
from accessing services secured by a CAPTCHA or other 
hot detection mechanisms. 


G. Filtering Spoofed Packets 

In most amplification attacks the attacker sends re¬ 
quests with the spoofed IP address of the victim. Fil¬ 
tering spoofed packets is considered one of the most 
effective countermeasures against amplification and other 
DoS attacks | [T^ , |[5^-|[60l. However, in 2005 the MIT 
ANA Spooler Project showed that around 25% of ASes 
allowed spoofed IP packets to be sent out of their net¬ 
work, and the ability of attackers to launch amplification 


attacks shows that it is still a problem today. Recent 
estimates state that it is still possible to send spoofed IP 


packets from about 20% of the Internet |58|. The next 
section will discuss spoofing in more delail and discuss 
some of fhe mefhods proposed fo defend againsl if. 

IV. Source IP Address Spooeing 

An inherenl requiremenl for amplificalion attacks in 
praclice is IP address spoofing. UDP and IP have no 
buill-in mechanism fo defermine if fhe source address is 
spoofed, so amplifiers reply fo fhe spoofed address in- 
slead of fhe original sender. Using spoofing for malicious 


purposes was firsl discussed in 1989 |24|, and a delailed 
analyses of fhe problem was carried oul by Heberlein and 


Bishop in 1996 |611, and again by Dunigan in 2001 |62|. 


Since fhen Ihere have been many ofher surveys related fo 
spoofing which we have summarized in Table These 
surveys can be broadly categorized as eilher focusing on 
spoofed packef defeclion/fillering | [6^ , ||64|, or fracing 
fhe attacker 


Chen and Yeung |43| also define Ihree common IP 


spoofing lechniques which all have differenl purposes, 
random spoofing, subnet spoofing, and fixed spoofing. In 
random spoofing, fhe attacker randomly generates source 
addresses for fhe attacking packefs. This lechnique is 
oflen used in TCP SYN flood attacks | |22l where fhe 
deslinafion of replies are nol relevanl fo fhe success of 
fhe attack bul fhe attacker still wanls fo obscure Iheir 
idenlily. In subnet spoofing fhe attacker will choose a 
source address in ils own subnef, which can help fo 
avoid some countermeasures such as ingress tillering, buf 
limils fhe number of possible vicfims. Fixed spoofing is 
fhe form of spoofing which is most commonly used in 
amplification attacks. This is where the attacker chooses 
the IP address of a single victim to be the source address 
on the spoofed packets, meaning that replies will be sent 
to the victim and not the attacker(s). 

We will start this section by discussing the techniques 
used to monitor spoofing and fo map nelworks which do 
nol guard againsl if. Laler we will (a) survey fhe conlri- 
bulions listed in Table |T^ in a single concise discussion, 
and (b) significanlly exlending fhe discussion fo include 
new approaches. This will involve calegorizing spoofing 
defenses as being for eilher packef tillering or Iraceback, 
as shown in Figure 

A. Monitoring Spoofing In The Wild 

There are Iwo techniques which are being used fo look 
al spoofing on the Internet. Active monitoring attempts 
to send spoofed packets and monitor the replies, while 
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TABLE II 

Survey papers eor eiltering spoofed IP packets and 
DETECTING ATTACKERS. 


Survey Name 


Papers Covered 

Detecting Spoofed Packets | 

m 

@-(zH 

IP Spoofing Defense: An Intro¬ 
duction |63[ 

(Z3)-(§ 

On the State of IP Spoofing De¬ 
fense |64[ 

(^, (^, f^l, 

(85)7 (8^(897^106)^ 

DDoS: Survey of Traceback 
Methods |66[ 

0, (i^-(nz) 

A Survey of IP Traceback 
Mechanisms to Overcome 
Denial-of-service Attacks |67| 

(TT^, (Id), (IT^-(m) 

A Survey on Packet Marking 
and Logging (68) 

ilTTol, fm), (ml, 

(T15|, (H^ |I20|-(I28| 

On IP Traceback (65| 


(42), (7^, JToill, JTot)- 
(m); (m), (12^(130) 


Detecting 

1^ and Filtering \-\ Correlation 
Spoofed Packets 


Spoofing 

Defenses 


Validating 

Source 

Addresses 


Flow 


Using Network 
Topology 


Peer-to-Peer 

Encrypting 
IP Packets 

Third-Parties 


Routing Tables | 

IP Headers ~| 

Ingress Filtering 
and RPF 


Learning 

Directions 


Tiaceback 


Using 

Traffic Logs 


Packet Marking I 


ICMP 

Traceback 


Link Testing 


Input 

Debugging 


Controlled 

Flooding 


Tunneling 
using IPSec 


Fig. 9. A categorization of source IP address spoofing defenses. 


passive monitoring requires analyses of Internet traffic, 
e.g, NetFlow data. In the following two subsections we 
examples of both approaches. 


1) Active Monitoring: The MIT Spoofer Project |58| 


measures how susceptible the Internet is to IP spoof¬ 
ing. To achieve a high coverage they have created and 
distributed an application which volunteers can install. 
The application sends several spoofed UDP packets to 
a server controlled by the project. The application then 
connects to the server using legitimate means to deter¬ 
mine which packets were received or lost. The results 
of the MIT Spoofer Project have shown that about 25% 
of ASs are currently vulnerable to IP spoofing. Daily 
sfatisfics are also available on their website |131| . 


Kiihrer et al. 1191 leverage the fact that some DNS 


proxies do not correctly change the IP addresses when 
forwarding DNS packets to test if their AS allows IP 
spoofing. They found 2,063 ASes that allow spoofed 
traffic by detecting if DNS replies have a different source 
IP addresses than the destination of the initial request. 


The disadvantage of their approach is that it relies on 
networks which have open DNS resolvers that do not 
change the source IP address on responses. However, 
their approach does not depend on the distribution of 
volunteers like the Spoofer Project, and the researchers 
were largely free to choose which networks to investigate 
due to the many available open DNS resolvers. 


2) Passive Monitoring: An orthogonal question to 
see who is spoofing, is to measure how much Internet 
traffic is actually being spoofed. The UCSD Network 
Telescope from CAIDA | |5^ is attempting to answer 
this question by monitoring traffic which is sent to 
darknets. A darknet is an address-space which is routable 
but where no traffic is expected to be sent, i.e., the 
addresses are not allocated. Monitoring traffic fo darknefs 
can be used to spot attacks, scans of the Internet, and 
misconfiguration of machines. 


To explain how a darknet can be used to detect spoofed 
packets we will briefly describe the steps of a TCP- 
SYN flooding attack |22|. When an attacker is using 
spoofing for a TCP-SYN flooding attack and randomly 
chooses a source address for the spoofed packets, there 
is a chance that the address is in the address space 
of the darknet. As a consequence, the victim of the 
attack will response to the spoofed addresses, and the 
SYN/ACK packets from the victim will appear as traffic 
fo fhe darknef. These SYN/ACK packets are known as 
backscatter, and since the darknets are supposed to cause 
no traffic, backscatter is assumed to be the result of 
spoofing once misconfiguration has been ruled out. 
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B. Validating the Source IP Address 

There is no built in mechanism in the Internet Protocol 
which can prevent spoofing. Its function is simply to 


provide best effort delivery of datagrams 1132|. Never¬ 
theless, over the next two subsections we will discuss 
various techniques which can be used to filter spoofed 
packets. In this section we will concentrate on methods 
which use some form of authentication to validate pack¬ 
ets as they arrive and filter those which are not validated. 
In the next section we will look at more probabilistic 
methods. 

1) End-to-End Address Verification: There are many 
end-to-end methods with which peers can attempt to 
validate the source IP address of packets. For example, 
probes can be used to provoke responses from the source 
address to see if it sent the packet 1^. However, 


packet loss means that some probes may be lost, and 
other unpredictable behaviour in the Internet means that 
probing cannot guarantee that the packet was spoofed. 

Additional information embedded in packets and 
which can be validated using a peer-to-peer network has 
been used to authenticate the source IP address |[75l. 


that datagrams can not be fragmented. It is also not 
clear how big MASK labels are, and if they will fit in 
the 16-bit ID field. Furthermore, MASK appears to be 
susceptible to eavesdropping attacks as MASK labels are 
not exchanged securely and are also sent in plain text in 
subsequent packets. 

Another example is the Source Address Validation 


Architecture with Host Identity Protocol (SAVAH) 11361, 
which can filter spoofed packets at the edge of local net¬ 
works. It requires that all end-hosts and gateway routers 


1 103| , | |133| , | |134| . This information can be 
unique between two peers, and may also have a time 
limit associated with it. The literature also uses different 
terminology to refer this data. Common notations are 
“cookie” 


support the Host Identity Protocol (HIP) | |I37| |, | |I38| |. 
SAVAH filters spoofed packets by requiring senders 
replace the source IP address of packets with a hash. 
The hash is created using the contents of each packet 
and a key agreed previously when the sender joined the 
network. This is cryptographically stronger than |133 1 
so long as the key was exchange securely. However, this 
approach degrades performance of the network rapidly 
due to the processing overheads of hashing every packet. 

2) Encryption: An overall more secure approach than 
appending validation data to packets is to encrypt all IP 
packets. Using encryption between peers would not only 
prevent most spoofing affacks, buf if also has fhe added 
benefif of all Infernef Iraffic being secure by defaulf |j^. 
One suifable mechanism by Gilad and Herzberg provides 


|98|, 11351 or “key” if fhe dafa is used in 
cryptographic functions |^, | |103[ , |136 |. 

Whilst the basic principle of using end-to-end methods 
to validate the source IP address is the same, all of the 
proposals have their own strengths and weaknesses. For 
example, large “puzzles” sent by servers may themselves 
be used in amplification attacks | |98| , and there are ad¬ 
ditional processing and space overheads associated with 
generating and stamping “passports” that are appended to 


packets |103|. Some of these overheads can be lowered, 
for example, if only routers at the edge of networks 
add data to, and validate, packets. However, this implies 
cooperation between network operators to install new 
functionality at the edges of their networks when the 
benefits to them may not outweigh the extra costs. 

Lu et al. | |133 1 proposed Multi-purpose Anti-Spoofing 
Key (MASK) where packets are tagged with MASK la¬ 
bels which are unique between the source and destination 
routers. At first, MASK labels are exchanged using a 
TCP connection. Then, MASK labels can be included 
in subsequent packets by overwriting the ID field in fhe 
IP header. However, MASK needs to be evaluated in 
more realistic scenarios. Overwriting the ID field means 


relatively lightweight encrypted communication |47|. 

However, the computational overheads and extra traf¬ 
fic caused by encrypfing all IP Iraffic is currenfly im- 
pracfical, and would also conflicl wifh loT scenarios 
using consfrained devices. Nevertheless, encryption can 
be used in select cases such as communication with 
amplifiers. 

3) Third-party Authentication: Sometimes if is nof 
desirable for roufers and end-poinfs fo use end-lo-end 
address verification, or negofiafe keys and encrypt pack¬ 
ets because of the additional processing and latency 
overheads. Using extra third-parties which are usually 
not involved in packet forwarding offers a way of 
authenticating packets which can potentially lower the 
extra processing demands placed on routers and end¬ 
points ||4gi, |[T39l-|[T4T|. 


For example, Gonzalez et al. |140| proposed that 


routers should send copies of packets to a “judge” 
(the trusted third-party). The judge should know the IP 
addresses serviced by the routers in order to make a 
decision whether or not the packet is spoofed, and the 
judge can also query routers in the absence of data. 

Noureldien et al. |45|, 1 141[ suggested that authenti¬ 
cation servers in local networks can be used to determine 
if TCP-SYN packets are spoofed. They propose that 
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all packets that exit a network are inspected by an 
authentication server. An authentication server can also 
check incoming packets with the authentication server at 
the source network. This approach can lower processing 
overheads for some hosts in the network but it does 
not address concerns about additional latency and traffic 
volume. 

C. Flow Correlation 

Flow telemetry can help to identify anomalies in 
network traffic by inspecting statistical information of 
traffic that is aggregated by source and destination ad¬ 
dresses/ports. Kreibich et al. proposed to inspect asym¬ 
metries in packet counts per flow direction to find reflec¬ 


tion attacks from the victim’s perspective 11421. Rossow 
proposed to leverage volume asymmetries to identify 
amplification attacks, both from the amplifier’s and vic¬ 


tim’s perspective |13|. Related methods that target non¬ 
amplification attacks aim to detect TCP-SYN flooding 
attacks by observing unbalanced SYN and SYN-ACK 
packet flows pi, 0, |[TT1, |[^, |[T44|. 


D. Filtering Spoofed Packets Using Network Topology 

Almost all of the filtering methods seen so far come 
with a high cost in terms of additional latency, traffic 
volume, and/or processing at routers. In this section we 
will discuss methods which can lower the overheads 
by using what information is already known about the 
structure of the Internet. For example, some IP addresses 
are not meant to be used outside of local networks. 
Packets with private IP addresses (e.g., 192.168.1.1) 
should not be routed, as Network Address Translation 
(NAT) 1 145| at the source network should have changed 
the source address of the packet. 

More generic methods of detecting spoofed packets, 
as discussed next, are probabilistic because the Internet 
is both dynamic and complex. However, some of these 
approaches also include a mechanism to determine if a 
packet was actually spoofed following detection. 

1) Using IP Headers: One way with which spoofed 
packets can be filtered without using additional band¬ 
width is to analyze information present in the IP headers. 
If the legitimate values for a source IP address is known, 
then spoofed packets which do not have the correct 
information can be identified and filtered. 

For example, spoofed packets can be filtered if their 
hop count does not match what is known about the 
topology of upstream routers. This information can be 
estimated using the Time To Live (TTL) field in the IP 


paths between the source and destination of spoofed 
packets. One interesting idea is to use Ant Colony 
Optimisation (ACO) algorithms to find these paths 1 147| |, 
and to collect TTL values which can be used to filter 
spoofed packets. 

It is even possible to filter spoofed packets by de¬ 
tecting what operating system a remote host is using. 


i.e., by estimating the initial TTL of packets |911, |93|. 
However, filtering spoofed packets based on the TTL 
and other fields does not guard against spoofing attacks 
where the attacker can manipulate the values in the IP 
header. 

2) Ingress Filtering and RPF: Filtering IP packets 
with spoofed addresses can be achieved using knowl¬ 
edge of the IP addresses allocated by the upstream or 
downstream networks | [73| , 1100|, | |148 1. Ingress filtering 
filters incoming packets. In contrast, egress filtering 
filters packets which are exiting the network. 

Ingress filtering (BCP 38) is sometimes implemented 
at the periphery of the Internet to stop packets with 
spoofed addresses being routed by edge routers 0. 
However, not all network operators implement BCP 
38. Ingress Access Lists are also typically maintained 
manually, and having outdated or misconfigured lists can 
prevent legitimate or allow spoofed traffic 1 102 | |. 

Unicast Reverse Path Forwarding (uRPF) is an imple¬ 
mentation of BCP 38 and uses forward routing informa¬ 


tion to filter spoofed packets |83|. Incoming packets are 


checked against a routers Forwarding Information Base 
(FIB) to ensure that packets are only forwarded if they 
come from the interface which is on the router’s best 
path to the source address. uRPF also has a “loose mode” 
where it can check the source addresses packets without 
taking the interface into account. This allowed uRPF 
to be used on routers with multiple links to multiple 
ISPs Q. 

3) Learning Directions: Routers can record informa¬ 
tion from incoming packets in order to filter traffic which 


comes from unexpected directions |74|, |78|-|80| 


11061. The Source Address Validity Enforcement (SAVE) 
protocol ]104 | is one example where routers can learn 
the expected incoming interface for a source address in 
order to authenticate subsequent packets. 


header |85|, |99|, |146|. However, there may be many 


The approach proposed by Wu et al. |89| is called 
Source Address Validation Architecture (SAVA). To pre¬ 
vent IP spoofing in a local network, SAVA routers bind 
the source IP address and MAC address to a specific 
switch port. The next step is to filter packets at the Intra- 
AS level. This is done by associating source addresses 
with the incoming interface. The last step, filtering 
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spoofed packets at inter-AS level, involves adjacent ASes 
exchanging address blocks so that packets from other 
ASes can be filtered. 

However, these methods do not perform well during 
legitimate changes to the Internet’s structure or when 


there are multiple paths between two routers |74|. To 


counter this problem these methods can consider multi¬ 
ple valid interfaces per source address at the cost of lower 


filtering accuracy. Mirkovic et al. |74| proposed dropping 
some TCP packets which originate from new interfaces. 
Under normal circumstances these packets should be 
retransmitted and the operation of the Internet is not 
severely compromised. However, this approach does not 
help with combating amplification attacks which are 
perpetrated using UDP or where the attacker retransmits 
attack packets. 

4) BGP and Routing Tables: BGP is responsible 
exchanging routing information between ASes. As a 
result, many papers have proposed that BGP can also 
be used to help filter spoofed packets |76|, |77|, 1 105| , 
e.g., by adding anti-spoofing information to BGP update 


messages 1811 using packet marking techniques such as 


Pi which we talk about in Section IIV-E2I 

One way to use BGP routing tables to filter 
spoofed packets is to use Distributed Packet Filtering 
(DPF) [7^ , and its extensions Inter-Domain Packet 
Filters (IDPF) fT^, | [T05| and Extended IDPF | |T34 |. 
Using IDPF a router examines BGP routing tables to 
check if it is on the optimal path between the packet’s 
source and destination. However, this approach suffers 
from the same security flaws as BGP because there is no 
built-in mechanism to check the integrity and source of 


BGP messages 1149|. To improve the security of BGP 


and thus IDPF, Dawakhar et al. have suggested using 


Credible BGP |150|. 


E. Tracing the Attacker 

Next to detecting and filtering spoofed IP packets, 
an orthogonal challenge is to trace the actual source 


of spoofed traffic 1651. Such tracing is useful, not only 


to stop attacks as they are happening by filtering the 
attack traffic at the source (thus saving the resources at 
upstream networks), but also so that the perpetrators can 
be prosecuted and further attacks prevented. 

Tracing spoofed packets is difficult because of limited 
access to external routers and the the high overheads 
involved. The existing traceback vary in their objective 
and where they are applied. For example, an adminis¬ 
trator of a local network might want to know which 
MAC address or interface is being used to send spoofed 


packets |151|, whereas an attack victim might want to 
know which network the attack originated from. 


In amplification attacks, the victim receives attack 
traffic from amplifiers. Thus, the traffic facing the victim 
is not spoofed. Instead, spoofing defection and tracebacks 
needs to be performed at the amplifiers, possibly wifh the 
help of amplification honeypots | |48| . 

It is also important to realize that the traceback can 
only be used to identify the source of spoofed packets. 
Detecting the individuals involved requires many out- 
band techniques such as monitoring the chat networks 
used by cyber criminals. Furthermore, tracing becomes 
inherently difficult in case of distributed attack sources, 
such as DDoS botnets. 


1) Using Traffic Logs: Tracing spoofed packets back 
to the attacker can be done by analyzing traffic flow 
data collected by routers | 113[ , |121|, 1144|. With log- 
based traceback there is always the potential to trace 
a single packet |143 1, and to trace attackers who use 
reflection. However, these methods often require that 


traffic data is either collected or stored by routers 1107|. 
This comes with many practical difficulties such as ad¬ 
ditional hardware costs, as was the case with the original 


proposal by Snoeren et al. 11131, which requires Source 
Path Isolation Engine (SPIE) routers in place of existing 
routers. One solution to replacing existing routers is to 
use tap devices which eavesdrop on traffic 1 152| |. Finally, 
one can lower the amount of storage required to trace 


attackers by using hashes |1211. 


2) Packet Marking: The idea of packet marking is 
to record the path which packets follow into the pack¬ 
ets (7TJ- Early packet marking schemes appended the IP 
addresses of routers into packets | |7T| , | |119 |. However, 
the four addition bytes needed to represent an IPv4 
address and the large number of hops quickly adds to the 
size of packets. Song and Perrig suggested reducing the 
amount of space required by encoding addresses using 
hashing and a map of upstream routers | 111[ . Yaar et 
al. discussed ways to lower the space needed by using 


shorter identifiers than IP addresses |82|. However, ap¬ 
pending data unnecessarily to packets is still undesirable 
because it can increase fragmentation. To address this 
problem some packet marking schemes also suggested 
overloading IP header fields | |7T| , | [86| , | [8^ , |[90|, [111 | 
and only encoding the addresses of edge routers |[87|. 


Savage et al. introduced Probabilistic Packet Marking 
(PPM) to reduce size and processing overheads of packet 
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marking even further |71|, 11 10||^[ PPM can be used 


to identify network path(s) traversed during an attack 
so long as the victim receives sufficient marked pack¬ 
ets. Dong et al. 1 154[ designed a single-bit-per-packet 
scheme. However, Adler | |92l noted that there is a trade¬ 
off between the number of bits allocated to PPM and the 
number of packets that must be received by the victim. 


Duwairi et al 1155| proposed a hybrid PPM and data 
storage method called Distributed Linked-List Traceback 
(DLLT). The “store, mark, and forward” operation used 
by DLLT requires a “marking field” in each packet 
big enough to store a single IP address, and a data 
structure on each router in which to store information 
about forwarded packets. Any router which marks a 
packet must first store the address in the marking field 
(if there is one) along with a packet identifier, then the 
router is free to write its address in the marking field 
before forwarding fhe packet. A linked list is inherently 
created using this operation because the address in the 
marking field points to the previous router, which has 
a record of where it received the packet from, and so 
on. However, its difficult to trace attacks with multiple 


attack sources |127|. To counter this. Song and Perrig 
looked at the security of markings and proposed using 


marked packets 11201 

A drawback of most packet marking schemes is that 
they rely on routers to maintain and update the markers. 
In case routers drop or do not extend the marks, packet 
marking becomes significantly less effective. 


3) ICMP Traceback: Bellovin et al. proposed iTrace 
where routers send ICMP messages to the destination 
address of packets they forward so that the destination 


can see the path which the packet followed 11091. ICMP 
traceback can also be probabilistic in that the chance 
of a router generating an ICMP message is small, thus 


lowering overheads in a similar way to PPM 11291, 11581, 


|159|. Mankin et al. improved iTrace with “intention- 
driven” traceback after they noticed that the chance of 
a router picking an attack packet close to the attacker 
is much smaller than closer to the victim for certain 
DoS attacks 1 129[ . Wang and Schulzrinne also proposed 
a new ICMP message which can be used in ICMP 


traceback for reflection attacks |160| . 

4) Link Testing: Link testing is the systematic testing 
of intermediary links between routers, such as imple¬ 
mented via input debugging |107| , DECIDUOUS fTOj , 
or controlled flooding |I08|, as described next. 

Input debugging attempts to determine from which 
upstream router an attack is coming from by recursively 
generating attack signatures to distinguish malicious 
packets from normal traffic. However, attack signatures 
that only match malicious traffic are difficulf fo creafe. 
Good atfack signafures mafch only attack fraffic and a 


lime-released key chains to authenticate them |1111. 

Li et al. proposed an efficient packet marking 
scheme specifically for reflection attacks called Authen¬ 
ticated Deterministic Packet Marking (ADPM), which is 
an extension of the approach proposed by Belenky et 
al. 1 156) . ADPM assumes that all routers are capable of 
matching request and response packets and that routers 
adjacent to reflectors cooperate to copy packet markings 
from the request packets to the replies. 

Dean et al. phrase packet marking as a polynomial 
reconstruction problem and encodes path information as 
points on polynomials | [90| . Chen and Lee also extended 
their work to target reflection attacks 1 157[ . They did this 
by requiring reflectors copy packet markings from the 
request packets to the replies. This enables the victim to 
trace paths to the attacker using less than 4,100 packets, 
but it may be possible to combine logging at routers 
and PPM to achieve traceback with a smaller number of 


only little to no legitimate traffic |107|. 

The Intruder Detection and Isolation Protocol 


(IDIP) | |72l describes an architecture which also uses 
attack signatures and can be used for link testing and 
attack mitigation. In IDIP a single Discovery Coordinator 
sends trace messages to other IDIP enabled devices. The 
trace messages contain a description of the event, i.e., 
an attack signature, using the Common Intrusion Spec¬ 


ification Language (CISL) |I6I|. IDIP devices which 
receive trace messages reply with report packets. The 
Discovery Coordinator can then decide what action to 
take, including instructing other IDIP devices to block 


attack traffic for a short amount of time |72|. 


Another link testing method uses IPSec |162|-|164| 
to trace the network from where a spoofed packet 
originated. For example, the DECIDUOUS implemen¬ 


tation 1701 creates secure tuimels between itself and up- 


Shokri et al. |153| had a similar idea 6 years later and called it 
Dynamic Marking. 


Stream routers until it finds fhe nefwork from where the 
attack is coming from. However, DECIDUOUS needs 
to have a complete overview of the network topology 
to choose routers with which to tunnel. Furthermore, 
DECIDUOUS has high processing and traffic overheads 
caused by sefting up and fearing down secure funnels. 

Controlled Flooding is a link testing method which 
floods each upstream router with packets. This technique 
needs the knowledge of the topology of the Internet. 
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Thus, a map of the Internet is obtained before link test¬ 


ing 11081. The purpose of flooding upstreaming routers 
is to determine if the attack traffic affected. If the attack 
traffic is disturbed significantly when sending traffic to 
a router then it is assumed that this particular router is 
one forwarding attack traffic. 

F. Discussion 

We have surveyed approaches to defend against spoof¬ 
ing. However, there are also more theoretical works in 
this area. For example, given a graph of the network 
topology and a set of firewall rules for each node, San- 
tiraveewan and Permpoontanalarp proposed a methodol¬ 


ogy which can check to see if spoofing is possible 11651. 


With all of these defenses, it may be confusing as 
to why spoofing is still a problem. There are many 
practical and economic reasons. Many of the proposals 
incur extra latency, traffic volume, computation, and/or 
storage overheads. Others are expensive to implement, 
as they require new hardware or staff to maintain them. 
Finally, it is not clear how well the methods will perform 
with only limited deployment |76|, and what rewards 


they offer to early adopters |811. 

We have seen that it is to difficult to prevent spoofing 
or trace the attackers in reflection/amplification attacks 
without considerable investment and cooperation by the 
different network operators. Therefore, we have to look 
for other ways of detecting and mitigating amplification 
attacks as soon as possible. The next section will address 
this topic in more detail. 

V. Detecting and Mitigating Amplification 
Attacks 


The preventative measures described in Sections III 


and IV are effective defences against amplification at¬ 
tacks. Nevertheless, we have seen that they cannot al¬ 
ways be relied upon. So the defences described in this 
section are to be used when preventative measures fail. 

Defending against amplification attacks involves at¬ 
tack detection and attack mitigation, e.g. packet filtering 
or black holing. Attack detection is easier to perform 
near to the victim because traffic flows resemble a funnel 
with many attackers sending packets to a single loca¬ 
tion pT[ . In contrast, attack mitigation is best performed 
closer to the source to save the resources of the victim 
and upstream networks. 

Chang 1421 explained that DoS defenses can be 
located at four areas: (i) the victim’s network, (ii) 
the victim’s ISP network, (iii) further upstream net¬ 
works, and (iv) attack source networks. Zargar et 


al. pT| classifies DoS defenses into two categories: (i) 
network/transport-level, and (ii) application-level. They 
also sub-categorized DoS defenses based on their de¬ 
ployment location: (i) source, (ii) destination, (iii) net¬ 
work, and (iv) distributed/hybrid. 

However, in this survey we are concerned specifically 
with amplification attacks, and we observed that it is also 
possible to defend against amplification attacks at the 
amplifiers. Therefore, we have have split amplification 
attack defenses into the following location categories 
described in Figure [TO} (i) at the victim’s network, (ii) at 
the source network(s), (iii) a single unspecified location 
in cases where the authors have not been clear about 
the deployment location, (iv) distributed, and (v) at the 
amplifier(s). In cases where the amplifier itself is the 
target of an amplification attack, defenses wifi be limited 
to source-based and amplifier-based defenses. 



Fig. to. Locations for defending against amplification attacks. 
Routers are marked x. 

It is also important to note that not all of the DoS de¬ 
fenses surveyed by Chang and Zargar et al. are applicable 
to amplification attacks. The most devastating attacks we 
described in Section [n| originated from multiple sources, 
and combined both traffic amplification and reflection. 
Therefore, in this section, we will discuss the defenses 
in Table [In] which include new proposals that specifically 
target amplification attacks, but we will also include 
some older proposals which can part-defend against 
amplification attacks, e.g., defenses against reflection. 
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TABLE III 

Methods for detecting and predicting amplification attacks. Some of these proposals also include novel 

TECHNIQUES WHICH AIM TO IDENTIFY AND FILTER ATTACK PACKETS. 


Method and References 

Description 

Location 

Time 

Before During 

Attack pattern correlation ]l66j 

Tries to detect reflection attacks by correlating the arrival 
rate of packets at the victim with known attacks. 

Victim 


/ 

Missing request packets (1^, (167)- 

m 

Attempt to match incoming responses to previously sent 
requests. 

Victim 


/ 

History-based IP Filtering (HIP) )17I| 

Attempts to filter packets during periods of high congestion 
which come from previously unseen addresses. 

Victim 


/ 

Comparing incoming and outgoing pack¬ 
ets at source networks (D-WARD) |172|, 

Uses protocol specific knowledge to predict the number 
of expected responses, e.g., replies to ICMP requests. Can 
also rate limit attacks at the source. 

Source 


/ 

Comparing the volume of incoming and 
outgoing traffic |174(, |175( 

MULTOPS and TOPS 

Unspecified 


/ 

Detection with Information Sharing 
(DIS) 

Aimed at TCP based reflection attacks, but reflectors 
collaborate to improve the accuracy of attack detection. 
Similar collaboration could potentially improve attack de¬ 
tection at amplifiers. 

Reflectors / 
Amplifiers 


/ 

PacketScore |177) 

Routers score packets, and communicate with a central 
server for a global view and filter packets with a high 
score. 

Distributed 


/ 

Repetitive packet sizes )178| 

Monitoring DNS packet sizes as well as the number of 
packets across multiple routers. Suspicion is based on 
thresholds calculated using real data from the GEANT 
network. 

Distributed 


/ 

Comparing payload bytes of request and 
response packets (13| 

Analysed NetFlow data to detect pair-flows where the 
response payloads are larger than the request payloads 
(a similar idea to that which is used in MULTOPS and 
TOPS). Limited to 14 UDP protocols. 

Distributed 


/ 

Comparing payload bytes of request and 
response packets, plus compare packet 
sizes of requests (20| 

Combines techniques from Rossow jl3) (comparing re¬ 
quest and response sizes) and Huistra |l78) (similar packet 
sizes between requests). 

Distributed 


/ 

Aggregate-based Congestion Control 
(ACC) 

Looks for high bandwidth aggregates (collections of pack¬ 
ets sharing the same destination address). Uses pushback 
(also used in |180)) to instruct upstream routers to rate- 
limit flows. 

Distributed 


/ 

Spoofing protection for amplifiers |135) 

Specific to amplification attacks. This method detects 
spoofed packets which do not have the correct session key 
provided by the amplifier for the source address. 

Distributed 


/ 

AD and PAD and TRACK 

A congested victim instructs upstream routers to use packet 
marking in order to trace the attack and then requests they 
filter the traffic. These methods may need to be updated 
for amplification attacks to take reflection into account. 

Distributed 


/ 

Game theory to predict attacks |183) 

It is possible to study the motivation of attackers and the 
security of the Internet to predict attacks. 

n/a 

/ 


Darknets to detect scans (184|- 

Monitoring darknet traffic can detect random scans for 
amplifiers such as those seen before the Spamhaus at¬ 
tack (TM). 

Distributed 

/ 


Honeypots to detect scans and at¬ 
tacks (13) 

Honeypots can take the place of amplifiers and are a 
powerful way of detecting scans and amplification attacks. 
They also require careful configuration so they do not 
cause harm to the victim. 

Amplifiers 

/ 

/ 
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A. Victim-end Defenses 


Despite attack detection and packet filtering being 
separate objectives, many proposals attempt to do both 
near tbe victim. 

Kambourakis et al. |15|, | |167 | proposed a DNS Am¬ 
plification Attacks Detector (DAAD) wbicb logs outgo¬ 
ing DNS requests and incoming responses in lookup 
tables at the victim’s network. Responses are matched 
to outgoing requests and responses that don’t match 
requests are flagged as suspicious. The authors also 
propose that the DAAD should be able to alter firewall 
rules to filter packets. However, amplification attacks do 
not only misuse DNS as we described in Section [T^ So 
a more general detection method is desirable. 


Tsunoda et al. |169| proposed a general method for 
matching request and response packets at a single point 
between the amplifier and fhe vicfim, e.g., af the vic¬ 
tim’s gateway router. They later extended their work 
with mathematical analysis and additional experimental 


results 1170|. However, in order to correctly identify 
the responses for each request, a router needs to record 
the source and destination addresses, protocol field, 
application headers, etc. for every request it forwards. 
This requires memory-intense management operations. 
A partial solution to this problem is to use Bloom 
filters to efficiently store requests and check them against 


incoming response packets 1168|. 


History-based IP Filtering (HIP) 1I7I| attempts to 


filter packets during periods of high congestion which 
come from previously unseen addresses. It does this by 
adding addresses to a table during normal operation, and 
uses a sliding window to remove expired addresses. 

Wei et al. 1 166| | proposed using traffic pattern corre¬ 
lation to look for patterns which are out of the ordinary, 
or which match known attack patterns. The advantages 
of using traffic pattern correlation and HIP for attack 
detection, are that they are lightweight and protocol 
independent. However, methods to detect attacks based 
on previous behavior can struggle to distinguish between 
attacks and unexpected bursts in legitimate traffic (flash 
crowds) P87| |. Furthermore, an attacker that knows these 
defenses can “train” the victim before the attack ||171||. 


After an attack has been identified, traffic can be 
dropped before if enters the victim network by in¬ 
strumenting the control plane. A common approach is 
blackholing of IP prefixes or hosf addresses af Internef 


Exchange Points (IXP) 11881. In this case, a border router 
of the victim network signals a specific next hop for the 
addresses under attack, using BGP updates. Traffic from 


neighboring roufers fo the victim will then be forwarded 
to this IP addresses (or more precisely to the MAC 
address), and finally discarded at IXP layer-2 ingress 
switches. 

Detecting attacks at the victim’s network may be 
ineffective because bandwidth may have already become 
saturated, or the volume of traffic is too much to process. 
This means that automated responses for filtering packets 
or alerting upstream routers to throttle traffic may not 
function correctly. In order to avoid this problem, another 
possible location for detecting and filtering amplification 
attacks is at the source network. 


B. Source-end Defenses 

Source-end defenses are desirable because they can 
stop attack traffic before it gets to upstream routers. 
However, source-end detection and filtering techniques 
may not be an effective defense against amplification 
attacks because: (i) the source of the attack can be dis¬ 
tributed, meaning that the solutions need to be deployed 
on all networks, (ii) it can be difficult to differentiate 
between legitimate and attack traffic if each aftacker only 
sends a few requesfs, and (iii) there is no immediate 
incentive for network providers to deploy source-end 
detection and filtering techniques because it is unclear 
what benefit it offers their customers. 

One example of a scheme proposed to work at the 
attack source is by Mirkovic et al. 1172|, |173|. They 
proposed D-WARD specifically fo detecf DoS aftacks 
which involve spoofed packets or high traffic volumes. 
They monitor both inbound and outbound traffic flows at 
the source network, and compare them with flow models 
derived from normal traffic. The authors also note that an 
attacker will not reduce its outbound traffic even when 
nofified of congestion at the victim, so D-WARD can rate 
limit suspected source addresses at upstream routers. 


C. Distributed Defenses 

Victim-end and source-end defenses tend to be de¬ 
signed to run in isolation on a single machine, e.g., at 
a border router between networks. However, detecting 
and filtering amplification attacks at a single point in the 
Internet is problematic because of asymmetric routing, 
and the fact that attacks are distributed. This means 
that in order for isolated defenses to be effective, all 
inbound and outbound paths in the Internet should be 
symmetrical, and all networks should support the new 
defenses. 

Amplification attacks are distributed threats against 
many potential victims, and as a result they require 
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distributed defenses. Some distributed defenses also 
can detect and filter attacks after a victim has been 
taken offline by the attack and cannot use automated 
methods which use the affected connections to alert 
upstream routers ||T3|, |[20|, ||177|, (178J. It is even 


between the amplifier and the victim |13|, |20|, |178|. 


detected specifically by monitoring DNS packet sizes 
as well as the number of packets across multiple 


possible to detect and filter DoS attacks with limited 
deployment of a distributed protocol alongside legacy 
equipment/protocols | |189 |. 

Kim et al. 1 177[ proposed PacketScore which uses 
a DDoS Control Server (DCS) to collate reports from 
routers across the Internet. Routers with special reporting 
capabilities, called Detecting-Differentiating-Discarding 
Routers (3D-R), mark suspicious packets with a “score” 
which reflects how likely they are to be involved in an 
attack. The 3D-Rs then filter packets based on a variable 
score threshold provided by the DCS, which varies the 
threshold depending on the current load at the victim and 
the score distribution of attacking packets. 

Mahajan et al. proposed attack detection at victims in 
terms of “aggregate” flows, and proposed using push- 
back mechanisms to filter flows at upstream networks 
whenever a link experiences sustained severe conges¬ 


routers |178|. Huistra’s method is split into two parts. 
The first (which can also be used to detect attackers) 
focuses on detecting IP addresses generating a suspicious 
number of similar sized DNS requests. Suspicion is 
based on thresholds calculated using real data from the 


GRANT network 1178|. The second part can be used to 
detect the victim, and looks at the number of large DNS 
packets sent to a single IP address. 

Rossow’s analysis and detection of amplification at¬ 
tacks is similar to Huistra’s but is not limited to a single 
protocol pA| . Instead, he focused on 14 UDP protocols 
which allow amplification. By analyzing traffic samples 
taken from routers belonging to a single ISP, Rossow was 
able to detect 15 real life amplification attacks against 
multiple victims by comparing sent and received bytes. 


tion 1179|. In pushback, the congested router asks up¬ 


stream routers which are involved in the flow aggregate 
to rate limit traffic flows | |1791 , |l80l . 


Chen and Park |181| proposed an Attack Diagnostic 
(AD) system in which DoS attacks are detected near to 
the victim, and packet filtering is executed close to the 
attacker. AD also combines some familiar techniques; 
packet marking (Section IV-E2[ ) is used for traceback, 
and an approach similar to pushback is used to alert the 
source networks. Similarly, TRACK combines packing 


marking with packet filtering 1182|. However, AD and 
Track are currently not suitable defenses for amplifica¬ 
tion attacks because their traceback methods will only 
trace back to the amplifier, but not to the actual attacker. 

It is also possible to detect amplification attacks by 
analyzing traffic flow data collected by multiple routers. 
Usually these methods require data from locations be¬ 
tween the source and the amplifier, as well as data from 


Based on the work by Rossow, Bottger et al. |20| 
developed a protocol-agnostic approach to detect ampli¬ 
fication attacks. They introduce the following detection 
criteria, which are independent of a specific network 
service, but base on the assumption that attackers reuse 
attack requests: (i) similar packet size among all requests 
(and responses), (ii) similar payload among all requests 
(and responses), (iii) an increased amount of ICMP 
unreachable messages, and (iv) incorrect TTL values. 
They found that the first two criteria are most suitable 
for amplification detection. 

D. Defenses At Reflectors/Amplifiers 

Rossow and Huistra also showed that it is possible 
to detect open DNS resolvers that have been abused in 
amplification attacks by analyzing traffic data collected 
by routers in a similar way as mentioned in the previ¬ 


ous subsection, but from an amplifiers perspective |13|, 


11781. 


Another approach for filtering spoofed packets, which 
was specifically designed to defend against amplification 
attacks, requires that session tokens are sent along with 


However, it is not required to have data from between 
the attacker and amplifier simply to detect DDoS attacks. 


Yu et al. 11871 proposed using flow correlation to detect 
DDoS attacks, but unlike the correlating method pro¬ 


posed by Wei et al. |166|, Yu’s method can distinguish 


attacks from flash crowds. This was possible because 
it has access to data collected by multiple routers in a 
“community network”. 

Huistra showed that amplification attacks can be 


requests to amplifiers |135|. This requires that the first 
time a request is received from a new address, the 
amplifier replies with a unique session token which the 
sender should include in all future requests. 

Including the same session token in all requests has 
low processing overheads but adds to the size of each 
packet. Furthermore, it is prone to eavesdropping if 
session tokens are not encrypted. If the attacker can 
eavesdrop on the victims Internet traffic then they can 
also agree new session tokens with amplifiers the victim 
has not yet contacted. 
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Peng et al. |176| focused on TCP based reflection 


attacks and used mechanics which might also improve 
the accuracy of detection at amplifiers. Their method 
monitored the cause of packets instead of just counting 
them. In their proposal, reflectors monitor incoming TCP 
RST packets and monitor those which have a corre¬ 
sponding SYN/ACK state for the outgoing connection. 
RST packets indicate that the reflector received a spoofed 
SYN packet from an attacker and sent a SYN/ACK to 
the victim, at which point the victim has replied with 
a RST packet. Peng et al. suggested that collaboration 
between reflectors can be used to improve the accuracy 
of attack detection. Once an attack has been detected, 
their system sends a warning to all other participating 
reflectors instructing them to stop the attack. 

E. Defenses at Single Unspecified Locations 

Not all DoS attack defenses are designed with a partic¬ 
ular location in mind, or the location was not explicitly 
specified. This is problematic because the challenges 
vary among locations. 

MUlti-Level Tree for On-line Packet Statistics (MUL- 


coming and outgoing traffic is proportional 11751. How¬ 


happen. To this end, Fultz et al. 11831 proposed using a 


It is also possible to detect scans for amplifiers which 
may act as a warning for future attacks. For example, 
darknets (also known as hlackholes) are unused IP ad¬ 
dress spaces on the Internet. Since the IP addresses in 
darknets are supposed to be unused, any traffic to or from 
a darknet is a sign of either scanning, misconfiguration. 


or malicious intent 1190|. 


Fachkha et al. | [T84l -| [T86l looked at 1.44TB of traffic 
data for a /13 address block of darknet IPs|^ and found 
134 separate incidents which they claimed may have 
been amplification attacks. 

However, Fachkha et al. may have detected scans for 
open DNS resolvers rather than actual attacks. To explore 
this idea we can look at Tables 7 and 8 in |1861 to see 
the incidents they detected. Specifically, they detected 
2 large events (February 19*^ and March 18*^) with 
very high packets per minute. March 18*^ is interesting 
because it is the same day as the Spamhaus attack Q. 
However, this looks like a horizontal IP scan because it 
targets 50,257 separate IPs with 1 packet each, which is 
indicative of a horizontal scan rather than an attack. 

We can also take a closer look at the Spamhaus 


TOPS) 11741 is one example where a router somewhere 
on the Internet is used to compare the volume of in¬ 
coming and outgoing traffic to look for DoS attacks. 
However, if MULTOPS is used on central routers which 
route packets for many different addresses, then the tree 
data structure it relies on will consume a significant 
amount of resources. In fact, MULTOPS itself can be 


targeted by memory exhaustion attack |174|, |175|. 

Tabulated On-line Packet Statistics (TOPS) |175[ im¬ 
proves on the accuracy of MULTOPS by taking into 
account the protocol being used, and also improves 
efficiency by using fixed length tables instead of trees. 
This makes TOPS suitable for use on busy links pT| . 

Both MULTOPS and TOPS assume that legitimate in¬ 


ever, this is not always the case, e.g., when streaming 
video. Attackers may also try to counteract MULTOPS 
and TOPS by trying to balance incoming and outgoing 
data volumes during an attack | [TT| . 

F. Predicting Future Attacks 

It is desirable to know about DoS attacks before they 


game theoretical approach to predict DDoS attacks. They 
found that attackers only launch attacks if defenders have 
not invested in adequate protection or if penalties, e.g, 
monetary costs and risks of being caught are low. 


incident by using Figure 6 of |186|, which shows the 
packets per hour going to the Darknet monitored by 
Farsight Security: 

• The first spike we are interested in is at 337 hours, 
which is on the 14*^ of March. This is shortly 
before the Spamhaus attack which was reported by 
CloudFlare as taking place on March 18^^ l[^. 

• The second interesting data spike at 385-409 hours 
is also before the attack. 

• The graph for the 18^^ of March (the day of the 
attack) is one of the quietest periods shown. 

• The next spike they detect is at 517 hours, which 
is 3 days after the attack. 

By referencing what we know about the Spamhaus 
attack 0, we suggest that the information presented by 
Fachkha et al. 1186| shows horizontal scans for open 
DNS resolvers which may be related to the Spamhaus 
attack. Furthermore, attackers are unlikely to waste band¬ 
width sending speculative requests to unknown IPs when 
they can try to maximise the impact of an attack by only 
sending requests to known amplifiers. This supported by 
the quiet period observed by Fachkha et al. on March 
IS*'*. 

Finally, to support defenses and monitor attacks, one 
can set up amplification honeypots that emulate protocols 

"^The data was provided to Fachkha et al. by Farsight Security 
https://www.farsightsecurity.com/. 
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that are vulnerable to amplification abuse. Honeypots 
can be used to log scanning activity and report attacks 
that abuse them. In addition, Kramer et al. show that 
honeypots can be used to derive signatures of attack 
traffic, such as domains abused in DNS requests [481, 
which is useful for detecting future attacks. 


G. Discussion 

Most of the defenses described in this section focus on 
amplification attack detection and filtering at the victim 
or by using distributed algorithms. Amplification attack 
defenses at the source networks are more desirable, but 
it is unlikely that defences specific fo a single allack, 
e.g., amplificalion attacks, will be implemenfed in fhe 
shorf-ferm and on a large scale. 

One confribufion of fhis paper is fo survey fhe defenses 
currenfly available for amplifiers and to make some 
suggestions for future directions. We found that this area 
has had relatively little attention compared to defenses at 
routers, but by adopting one of the approaches detailed 
in Section]^ it may be possible for amplifiers to prevent 
amplification attacks from happening in the first place. 


VI. Conclusions 


TABLE IV 

Initiatives to Identify Amplifiers 


Reference 

Description 

Open Resolver 
Scanning 

Project |191| 

Scans for open DNS resolvers and provide an 
automated system to notify affected networks. 

Open DNS 

Resolver 

Project (2^ 

Scans for open resolvers and allows to query 
for such resolvers in a certain IP address range. 

Measurement 
Eactory |192| 

Maintains a list of DNS servers that are known 
to serve as globally accessible open resolvers. 

Open NTP 

Project |193| 

Scans for NTP servers in IPv4 which can be 
used in an amplification attack. 


can mitigate attacks even when the victim has gone off¬ 
line and is unable to take counter-measures itself. How¬ 
ever, these methods require more collaboration between 
network providers than is currently the case O- 
More research is required to close the attack vectors 
which are being used in amplification attacks, e.g, clos¬ 
ing open DNS resolvers, patching NTP servers, and pro¬ 
moting ingress filtering. A number of ongoing initiatives 


aim at tackling these issues, as summarized in Table IV 


This paper discusses the current state of the art of 
research proposals for detecting, preventing, and tracing 
amplification attacks. As part of this, we have also 
surveyed defenses against source IP address spoofing, 
which is essenfial for amplificafion affacks. 

We have concluded fhaf prevenfing source IP spoofing 
is fhe effecfive way of defending againsf amplification 
attacks. However, spoofed packets can still be sent from 
large parts of the Internet. So we need effective methods 
to detect and filter DoS attack packets as close to the 
source as possible. 

Another subject for future work is to assess the de¬ 
fenses we have covered against one another using a wider 
list of empirical criteria, e.g., monetary cost, accuracy, 
memory overheads, levels of inter-AS cooperation, etc. 
Zargar et al. | [TT| surveyed the metrics used to asses DoS 
defenses and discussed their categorization in some of 
these terms. However, a more detailed study on individ¬ 
ual defenses is crucial because all of the proposals we 
surveyed come with their own strengths and weaknesses. 
Some of which may not be obvious, and it is important 
for system administrators to be able to weigh up their 
options in a concise and meaningful way. 

Promising amplification attack defences appear to be 
distributed DoS detection and filtering algorithms, which 


References 

[1] M. Handley, E. Rescorla, and lAB, “Internet Denial-of- 
Service Considerations,” REC 4732 (Informational), Internet 
Engineering Task Eorce, December 2006. [Online], Available: 
http ://w w w. ietf. org/rfc/rfc4732. txt 

[2] T. Brewster, “Cyber Attacks Strike Zimbabweans 
Around Controversial Election,” August 2013. [On¬ 
line]. Available: http://www.techweekeurope.co.uk/workspace/ 
zimbabwe-election-cyber-attacks-123938 

[3] J. Leyden, “US Credit Card Eirm Fights DDoS Attack,” 
September 2004. [Online]. Available: http://www.theregister. 
co.uk/2004/09/23/authorize ddos attack/ 

[4] Prolexic, “Prolexic Stops Largest-Ever DNS Reflection 
DDoS Attack ,” May 2013. [Online]. Available: http: 
//WWW. tinyurl.com/prolexic-167ghit 

[5] A. Pras, A. Sperotto, G. Moura, I. Drago, R. Barbosa, R. Sadre, 
R. Schmidt, and R. Hofstede, “Attacks hy Anonymous Wik¬ 
iLeaks Proponents not Anonymous,” 2010. 

[6] M. Calce and C. Silverman, Mafiaboy: How I Cracked the 
Internet and Why It’s Still Broken. Viking, 2008. 

[7] D. Takahashi, “Hackers Attack Dota 2 and League 

of Legends Servers in Quest Eor One Game 

Livestreamer,” December 2013. [Online]. Available: 
http://tinyurl.com/PhantomLOrd-drdos 

[8] I. M. Prince; CloudPlare, “The DDoS That Almost 
Broke the Internet,” March 2013. [Online]. Available: http: 
//hlog.cloudfl are.com/the-ddos-that-almost-broke-the-intemet 

[9] J. Mirkovic and P. Reiher, “A Taxonomy of DDoS Attack 
and DDoS Defense Mechanisms,” ACM SIGCOMM Comput. 
Commun. Rev., vol. 34, no. 2, pp. 39-53, Apr. 2004. 


20 










[10] C. Douligeris and A. Mitrokotsa, “DDoS Attacks and Defense 
Mechanisms: Classification and State-of-the-art,” Computer 
Networks, vol. 44, no. 5, pp. 643 - 666, 2004. 

[11] S. Zargar, J. Joshi, and D. Tipper, “A Survey of Defense 
Mechanisms Against Distributed Denial of Service (DDoS) 
Flooding Attacks,” Communications Surveys Tutorials, IEEE, 
vol. 15, no. 4, pp. 2046-2069, 2013. 

[12] Y. Li, Q. Wang, F. Yang, and S. Su, “Traceback DRDoS 
Attacks,” Journal of Information & Computational Science, 
vol. 8, pp. 94-111, 2011. 

[13] C. Rossow, “Amplification Hell: Revisiting Network Protocols 
for DDoS Abuse,” in Proc. of NDSS. Internet Society, 2014. 

[14] R. Vaughn and G. Evron, “DNS Amplification 

Attacks,” March 2006. [Online]. Available: http: 

//crt.io/DNS-Amplification-Attacks.pdf 

[15] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis, 

“A Fair Solution to DNS Amplification Attacks,” 2nd Inter¬ 
national Workshop on Digital Forensics and Incident Analysis 
(WDFIA 2007), pp. 38^7, 2007. 

[16] R. Shankesi, M. AlTurki, R. Sasse, C. A. Gunter, 

and J. Meseguer, “Model-checking DoS Amplification for 
VoIP Session Initiation,” in Computer Security-ESORICS. 
Springer, 2009, pp. 390^05. 

[17] M. Anagnostopoulos, G. Kambourakis, P. Kopanos, 

G. Louloudakis, and S. Gritzalis, “DNS Amplification 
Attack Revisited,” Comput. Secur, vol. 39, pp. 475-485, Nov. 
2013. 

[18] X. Ye and Y. Ye, “A Practical Mechanism to Counteract 
DNS Amplification DDoS Attacks,” Journal of Computational 
Information Systems, vol. 9, pp. 265-272, 2013. 

[19] M. Kiihrer, T. Hupperich, C. Rossow, and T. Holz, “Exit from 
Hell? Reducing the Impact of Amplification DDoS Attacks,” 
in Proc. of the 23rd USENIX Security Symposium. USENIX 
Assoc., 2014. 

[20] T. Bottger, L. Braun, O. Gasser, F. von Eye, H. Reiser, and 
G. Carle, “DoS Amplification Attacks - Protocol-Agnostic 
Detection of Service Abuse in Amplifier Networks,” in 7th 
International Workshop on Traffic Monitoring and Analysis 
(TMA), vol. 9053. Springer-Verlag, 2015, pp. 205-218. 

[21] R. R. Hansen, “Slowloris,” 2009. [Online]. Available: 
http://en. Wikipedia. org/wiki/Slowloris_(software) 

[22] W. Eddy, “TCP SYN Elooding Attacks and Common 
Mitigations,” RFC 4987 (Informational), Internet Engineering 
Task Force, August 2007. [Online]. Available: http://www. 
ietf. org/rfc/rfc4987. txt 

[23] D. Cornell, “DNS Amplification Attacks,” March 2014. 
[Online]. Available: https://labs.opendns.eom/2014/03/17/ 
dns- amplification- attacks/ 

[24] S. M. Bellovin, “Security Problems in the TCP/IP Protocol 
Suite,” ACM SIGCOMM Comput. Commun. Rev., vol. 19, 
no. 2, pp. 32-48, Apr. 1989. 

[25] M. Prince, “Technical Details Behind a 400Gbps 

NTP Amplification DDoS Attack,” Feb 2014. 
[Online]. Available: http://blog.cloudflare.com/ 

technical-details-behind-a-400gbps-ntp-amplification-ddos-attack 

[26] “Open Resolver Project,” April 2015. [Online]. Available: 
http://openresolverproject.org 

[27] AusCERT, “Domain Name System (DNS) Denial of Service 
(DoS) Attacks,” August 1999. [Online]. Available: http: 
//www.securityfocus.com/advisories/1727 

[28] P. I. Criscuolo, “Distributed denial of service - trinOO, tribe 
flood network, tribe flood network 2000,” Technical Report 
CIAC-2319, Department of Energy-CIAC (Computer Incident 
Advisory Capability), Tech. Rep., 2000. 


[29] J. Damas, M. Graff, and P. Vixie, “Extension Mechanisms for 
DNS (EDNS(O)),” IETF, RFC 6891, April 2013. 

[30] US-CERT, “UDP-based Amplification Attacks,” 2014. 

[Online]. Available: https://www.us-cert.gov/ncas/alerts/ 

TA14-017A 

[31] Akamai, “SSDP Reflection DDOS Attacks,” 

2014. [Online]. Available: http://www.prolexic. 

com/kcresources/attack-report/attack_report_q214/ 
Prolexic-Q22014-Global-Attack-Report-A4.pdf 

[32] MIT, “2013-05-16 SNMP Amplification Attack,” May 2013. 
[Online]. Available: http://tinyurl.com/MIT-drdos 

[33] US-CERT, “NTP Amplification Attacks Using CVE-2013- 
5211,” 2014. [Online]. Available: https://www.us-cert.gov/ 
ncas/alerts/TA14-013A 

[34] Akamai, “The State of the Internet [security],” September 
2014. [Online]. Available: http://www.stateoftheinternet.com/ 
resources- web- security- 2014- q4- internet- security-report.html 

[35] CERT Advisory, “Smurf IP Denial of Service Attacks,” 
1998. [Online]. Available: http://www.cert.org/advisories/ 
CA-1998-01.html 

[36] S. Kumar, “Smurf-based Distributed Denial of Service (DDoS) 
Attack Amplification in Internet,” in Proceedings of the Second 
International Conference on Internet Monitoring and Protec¬ 
tion. IEEE, 2007. 

[37] A. Householder, A. Manion, L. Pesante, G. Weaver, and 
R. Thomas, “Managing the Threat of Denial-of-service 
Attacks,” 2001. [Online]. Available: http://resources.sei.cmu. 
edu/library/asset-view.cfm?assetid=52481 

[38] R. Sparks, “Addressing an Amplification Vulnerability 
in Forking Proxies,” 2006. [Online]. Available: https: 
//tools .ietf.org/html/draft- ietf- sip-fork- loop- fix- 00 

[39] T. Brewster, “Prolexic CEO: Biggest Cyber Attack Ever 
Was Built on Lies,” April 2013. [Online]. Available: 
http://tinyurl.com/pr4j42d 

[40] T. Rozekrans, M. Mekking, and J. de Koning, “Defending 
Against DNS Reflection Amplification Attacks,” University of 
Amsterdam, Tech. Rep., February 2013. 

[41] V. Paxson, “An Analysis of Using Reflectors for Distributed 
Denial-of-service Attacks,” ACM SIGCOMM Comput. Com¬ 
mun. Rev., vol. 31, no. 3, pp. 38-47, Jul. 2001. 

[42] R. Chang, “Defending against flooding-based distributed 
denial-of-service attacks: A tutorial,” Communications Mag¬ 
azine, IEEE, vol. 40, no. 10, pp. 42-51, Oct 2002. 

[43] W. Chen and D.-Y. Yeung, “Defending Against TCP SYN 
Flooding Attacks Under Different Types of IP Spoofing,” in 
International Conference on Networking, International Con¬ 
ference on Systems and International Conference on Mobile 
Communications and Learning Technologies. IEEE, April 
2006. 

[44] S. H. D. Nashat, Xiaohong Jiang, “Detecting SYN Elooding 
Agents under Any Type of IP Spoofing,” in IEEE International 
Conference on e-Business Engineering. IEEE, October 2008, 
pp. 499-505. 

[45] M. O. H. N. A. Noureldien, “Block Spoofed Packets at Source 
(BSPS): A Method for Detecting and Preventing all Types 
of Spoofed Source IP Packets and SYN Elooding Packets at 
Source: A Theoretical Eramework,” in Second International 
Conference on the Applications of Digital Information and 
Web Technologies. IEEE, Aug 2009, pp. 579-583. 

[46] L. Kavisankar and C. Chellappan, “A Mitigation Model for 
TCP SYN Flooding with IP spoofing,” in International Con¬ 
ference on Recent Trends in Information Technology (ICRTIT). 
IEEE, June 2011, pp. 251-256. 


21 


[47] Y. Gilad and A. Herzberg, “LOT: A Defense Against IP 
Spoofing and Flooding Attacks” ACM Trans. Inf. Syst. Secur., 
vol. 15, no. 2, pp. 6:1-6:30, M. 2012. 

[48] L. Kramer, J. Krupp, D. Makita, T. Nishizoe, T. Koide, 
K. Yoshioka, and C. Rossow, “AmpPot: Monitoring and 
Defending Amplification DDoS Attacks,” in Proceedings of 
the 18th International Symposium on Research in Attacks, 
Intrusions and Defenses, November 2015. 

[49] M. Feily, A. Shahrestani, and S. Ramadass, “A Survey of Bot¬ 
net and Botnet Detection,” in Proceedings of the 2009 Third 
International Conference on Emerging Security Information, 
Systems and Technologies. IEEE, 2009. 

[50] Praetox, “LOIC - A Network Stress Testing Application.” 
[Online]. Available: http://sourceforge.net/projects/loic/ 

[51] V. Jacobson, D. K. Smetters, J. D. Thornton, M. E. Plass, N. H. 
Briggs, and R. L. Braynard, “Networking Named Content,” in 
Proceedings of the 5th International Conference on Emerging 
Networking Experiments and Technologies. ACM, 2009, pp. 
1 - 12 . 

[52] T. Anderson, T. Roscoe, and D. Wetherall, “Preventing Internet 
Denial-of-service with Capabilities,” Computer Communica¬ 
tion Review, vol. 34, no. 1, pp. 39^4, 2004. 

[53] X. Yang, D. Wetherall, and T. Anderson, “TVA: A DoS- 
limiting Network Architecture,” Networking, lEEE/ACM 
Transactions on, vol. 16, no. 6, pp. 1267-1280, 2008. 

[54] J. Meseguer, “Rewriting Logic and Maude: A Wide-Spectrum 
Semantic Framework for Object-Based Distributed Systems,” 
in Formal Methods for Open Object-Based Distributed Systems 
IV. Springer US, 2000, vol. 49, pp. 89-117. 

[55] Valve, “Steam Master Server Query Protocol,” 2015. 
[Online]. Available: https://developer.valvesoftware.com/wiki/ 
Master s erver Query Protocol 

[56] S. Kandula, D. Katabi, M. Jacob, and A. Berger, “Botz- 
4-sale: Surviving organized ddos attacks that mimic flash 
crowds,” in Proceedings of the 2nd conference on Symposium 
on Networked Systems Design & Implementation — Volume 2. 
USENIX Association, 2005, pp. 287-300. 

[57] G. Oikonomou and J. Mirkovic, “Modeling human behavior 
for defense against flash-crowd attacks,” in IEEE International 
Conference on Communications. ICC’09. IEEE, 2009, pp. 1- 
6 . 

[58] R. Beverly and S. Bauer, “The Spooler Project: Inferring the 
Extent of Source Address Eiltering on the Internet,” USENIX 
SRUTI: Steps to Reducing Unwanted Traffic on the Internet 
Workshop, pp. 53-59, Jul. 2005. 

[59] D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, and 
S. Savage, “Inferring Internet denial-of-service activity,” ACM 
Trans. Comput. Syst., vol. 24, no. 2, pp. 115-139, 2006. 

[60] J. Mauch, “SNMP DDoS: The Vulnerability You Might Not 
Know You Have,” http://seclists.org/nanog/2013/Aug/132, Au¬ 
gust 2013. 

[61] L. T. Heberlein and M. Bishop, “Attack Class: Address 
Spoofing,” in Proc. of the 19th National Information Systems 
Security Conference, 1996, pp. 371-377. 

[62] T. Dunigan, “Backtracking Spoofed Packets,” 2001. [Online]. 
Available: http://www.epm.oml.gov/~dunigan/oci/back.ps 

[63] L. Soon, M. Othman, and N. 1. Udzir, “IP Spoofing Defense: 
An Introduction,” International Conference on Computing & 
Informatics (ICOCI09), 2009. 

[64] T. Ehrenkranz and J. Li, “On the State of IP Spoofing 
Defense,” ACM Trans. Internet TechnoL, vol. 9, no. 2, pp. 
1-29, May 2009. 


[65] A. Belenky and N. Ansari, “On ip traceback,” Communications 
Magazine, IEEE, vol. 41, no. 7, pp. 142-153, 2003. 

[66] A. John and T. Sivakumar, “DDoS: Survey of Traceback Meth¬ 
ods,” International Journal of Recent Trends in Engineering, 
vol. 1, no. 2, pp. 241-245, May 2009. 

[67] S. Vincent and J. 1. J. Raja, “A Survey of IP Traceback Mech¬ 
anisms to Overcome Denial-of-service Attacks,” Proceedings 
of the 12th International Conference on Networking, VLSI and 
Signal Processing, pp. 93-98, 2010. 

[68] R. Jain and P. A. Meshram, “A Survey on Packet Marking 
and Logging,” International Journal of Computer Science and 
Information Technologies (IJCSIT), vol. 4, no. 3, pp. 426-429, 
2013. 

[69] S. J. Templeton and K. E. Levitt, “Detecting Spoofed Packets,” 
in DARPA Information Survivability Conference and Exposi¬ 
tion, 2003, April 2003, pp. 164-175. 

[70] H.-Y. Chang, R. Narayan, S. F. Wu, B. Vetter, X. Wang, 
M. Brown, J. Yuill, C. Sargor, Y. F. Jou, and F. Gong, “Decld- 
UouS: Decentralized Source Identification for Network-Based 
Inlmmowf m Integrated Network Management. IEEE, 1999, 
pp. 701-714. 

[71] S. Savage, D. Wetherall, A. R. Karlin, and T. E. Anderson, 
“Practical Network Support for IP Traceback,” in Proc. of 
ACM SIGCOMM. ACM, 2000, pp. 295-306. 

[72] D. Schnackenberg, K. Djahandari, and D. Sterne, “Infras- 
tmcture for Intrusion Detection and Response,” in DARPA 
Information Survivability Conference and Exposition, vol. 2, 
2000, pp. 3-11. 

[73] P. Ferguson and D. Senie, “Network Ingress Filtering: De¬ 
feating Denial of Service Attacks which employ IP Source 
Address Spoofing,” IETF, RFC 2827, May 2000. 

[74] J. Mirkovic, N. Jevtic, and P. Reiher, “A Practical IP Spoof¬ 
ing Defense Through Route-Based Fltering,” University of 
Delaware, CIS department. Technical Report, CIS-TR, 2006. 

[75] A. Bremler-barr and H. Levy, “Spoofing Prevention Method,” 
in Proc. IEEE INFOCOM, 2005, pp. 536-547. 

[76] K. Park and H. Lee, “On the Effectiveness of Route-based 
Packet Filtering for Distributed DoS Attack Prevention in 
Power-law Internets,” ACM SIGCOMM Comput. Commun. 
Rev., vol. 31, no. 4, pp. 15-26, Aug. 2001. 

[77] Z. D. X. Yuan and J. Chandrashekar, “Controlling IP Spoofing 
through Interdomain Packet Filters,” in Dependable and Se¬ 
cure Computing, IEEE Transactions on, vol. 5. IEEE, March 
2008, pp. 22-36. 

[78] T. Ohtsuka, F. Nakamura, Y. Sekiya, and Y. Wakahara, “Pro¬ 
posal and Efficient Implementation of Detecting and Eiltering 
Method for IP Spoofed Packets,” in International Conference 
on Information and Communication Technology. IEEE, 
March 2007, pp. 327-330. 

[79] J. Li, J. Mirkovic, T. Ehrenkranz, M. Wang, P. Reiher, and 
L. Zhang, “Learning the Valid Incoming Direction of IP 
Packets,” Computer Networks, vol. 52, no. 2, pp. 399-417, 
2008. 

[80] C. A. Shue, M. Gupta, and M. P. Davy, “Packet Forwarding 
with Source Verification,” Comput. Netw., vol. 52, no. 8, pp. 
1567-1582, Jun. 2008. 

[81] H. Lee, M. Kwon, G. Hasker, and A. Perrig, “BASE: An 
Incrementally Deployable Mechanism for Viable IP Spoofing 
Prevention,” in Proc. of the 2nd ACM ASIACCS. ACM, 2007, 
pp. 20-31. 

[82] A. Yaar, A. Perrig, and D. X. Song, “Pi: A Path Identification 
Mechanism to Defend against DDoS Attack,” in Proc. of IEEE 
Symposium on Security and Privacy. IEEE, 2003. 


22 


[83] Cisco Systems, “Unicast Reverse Path Forwarding Enhance¬ 
ments For The Internet Service Provider — Internet Service 
Provider Network Edge,” Cisco, White Paper, 2005. 

[84] G.-F. Lv and Z.-G. Sun, “Towards Spoofing Prevention Based 
on Hierarchical Coordination Model,” in Proc. of Workshop on 
Hish Performance Switching and Routine (HPSR’07). IEEE, 
June 2007, pp. 1-6. 

[85] H. Wang, C. Jin, and K. G. Shin, “Defense Against Spoofed IP 
Traffic Using Hop-count Filtering,” lEEE/ACM Trans. Netw., 
vol. 15, no. 1, pp. 40-53, Feb. 2007. 

[86] A. Yaar, A. Perrig, and D. Song, “StackPi: New Packet 
Marking and Filtering Mechanisms for DDoS and IP Spoofing 
Defense,” IEEE Journal on Selected Areas in Communications, 
vol. 24, no. 10, pp. 1853-1863, 2006. 

[87] Z. Gao and N. Ansari, “A Practical and Robust Inter-domain 
Marking Scheme for IP Traceback,” Computer Networks, 
vol. 51, no. 3, pp. 732-750, 2007. 

[88] R. Chen, J.-M. Park, and R. Marchany, “A Divide-and- 
Conquer Strategy for Thwarting Distributed Denial-of-Service 
Attacks,” Parallel and Distributed Systems, IEEE Transactions 
on, vol. 18, no. 5, pp. 577-588, May 2007. 

[89] J. Wu, G. Ren, and X. Li, “Source Address Validation: Ar¬ 
chitecture and Protocol Design,” in Network Protocols, 2007. 
ICNP 2007. IEEE International Conference on. IEEE, 2007, 
pp. 276-283. 

[90] D. Dean, M. K. Franklin, and A. Stubblefield, “An Algebraic 
Approach to IP traceback,” ACM Trans. Inf. Syst. Secur., vol. 5, 
no. 2, pp. 119-137, 2002. 

[91] G. Taleck, “Ambiguity Resolution via Passive OS Fingerprint¬ 
ing,” in Recent Advances in Intrusion Detection, ser. Lecture 
Notes in Computer Science. Springer, 2003, vol. 2820, pp. 
192-206. 

[92] M. Adler, “Trade-offs in Probabilistic Packet Marking for IP 
Traceback,” J. ACM, vol. 52, no. 2, pp. 217-244, Mar. 2005. 

[93] Fyodor, “Remote OS Detection,” 2006. [Online]. Available: 
http://nmap.org/book/osdetect.html 

[94] S. Kent and K. Seo, “Security Architecture for the 
Internet Protocol,” RFC 4301 (Proposed Standard), Internet 
Engineering Task Force, December 2005. [Online]. Available: 
http://www.ietf.org/rfc/rfc4301.txt 

[95] R. Beverly, “A Robust Classifier for Passive TCP/IP Finger¬ 
printing,” in Proc. of 5th International Workshop on Passive 
and Active Network Measurement (PAM). Heidelberg Berlin: 
Springer, 2004, pp. 158-167. 

[96] G. Taleck, “Ambiguity Resolution via Passive OS Fingerprint¬ 
ing,” in Proc. of RAID. Springer, 2003, pp. 192-206. 

[97] B. Bemtein, “SYN Cookies,” 1996. [Online]. Available: 
http://cr.yp.to/syncookies.html 

[98] W. Feng, E. Kaiser, W. Feng, and A. Luu, “Design and 
implementation of network puzzles,” in INEOCOM 2005. 
24th Annual Joint Conference of the IEEE Computer and 
Communications Societies. Proceedings IEEE, vol. 4, March 
2005, pp. 2372-2382 vol. 4. 

[99] C. Jin, H. Wang, and K. G. Shin, “Hop-count Filtering: An 
Effective Defense Against Spoofed DDoS Traffic,” in Proc. of 
the 10th ACM CCS. ACM, 2003, pp. 30^1. 

[100] T. Killalea, “Recommended Internet Service Provider Security 
Services and Procedures,” RFC 3013 (Best Current Practice), 
Internet Engineering Task Force, Nov. 2000. [Online]. 
Available: http://www.ietf.org/rfc/rfc3013.txt 

[101] F. Baker, “Requirements for IP Version 4 Routers,” RFC 
1812 (Proposed Standard), Internet Engineering Task Force, 


June 1995, updated by RFC 2644. [Online]. Available: 
http://www.ietf.org/rfc/rfc 1812.txt 

[102] F. Baker and P. Savola, “Ingress Filtering for Multihomed 
Networks,” RFC 3704 (Best Current Practice), Internet 
Engineering Task Force, March 2004. [Online]. Available: 
http://www.ietf.org/rfc/rfc3704.txt 

[103] X. Liu, A. Li, X. Yang, and D. Wetherall, “Passport: Secure 
and Adoptable Source Authentication,” in Proceedings of the 
5th USENIX Symposium on Networked Systems Design and 
Implementation. USENIX Association, 2008, pp. 365-378. 

[104] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang, “SAVE: 
Source address validity enforcement protocol,” in IEEE IN¬ 
EOCOM, 2002, pp. 1557-1566. 

[105] Z. Duan, X. Yuan, and J. Chandrashekar, “Constructing Inter- 
Domain Packet Filters to Control IP Spoofing Based on BGP 
Updates,” in Proc. of IEEE INEOCOM, 2006, pp. 1-12. 

[106] T. Ehrenkranz and J. Li, “An Incrementally Deployable Pro¬ 
tocol for Learning the Valid looming Direction of IP Packets,” 
University of Oregon, Tech. Rep., October 2007. 

[107] R. Stone, “Centertrack: An IP Overlay Network for Tracking 
DoS Floods,” in Proc. of the 9th conference on USENIX 
Security Symposium. USENIX Association, 2000, pp. 15- 
15. 

[108] H. Burch and B. Cheswick, “Tracing Anonymous Packets to 
Their Approximate Source,” in Proc. of the 14th Conference 
on Systems Administration (LISA 2000). USENIX, December 
2000, pp. 319-327. 

[109] S. Bellovin and M. Leech, “ICMP Traceback Messages,” 
February 2000. [Online]. Available: https://tools.ietf.org/html/ 
draft- ietf- itrace- 00 

[110] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Network 
Support for IP Traceback,” lEEE/ACM Trans. Netw., vol. 9, 
no. 3, pp. 226-237, Jun. 2001. 

[111] D. X. Song and A. Perrig, “Advanced and Authenticated Mark¬ 
ing Schemes for IP Traceback,” in Proc. of IEEE INEOCOM, 
vol. 2, 2001, pp. 878-886. 

[112] A. Belenky and N. Ansari, “Accommodating Fragmentation in 
Deterministic Packet Marking for IP Traceback,” in Proceed¬ 
ings of IEEE Global Telecommunications Conference, 2003, 
pp. 1374-1378. 

[113] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, 
F. Tchakountio, B. Schwartz, S. T. Kent, and W. T. 
Strayer, “Single-packet IP traceback.” lEEE/ACM Trans. 
Netw., vol. 10, no. 6, pp. 721-734, 2002. 

[114] Y. Xiang, W. Zhou, and M. Guo, “Flexible Deterministic 
Packet Marking: An IP Traceback System to Find the Real 
Source of Attacks,” IEEE Transactions on Parallel and Dis¬ 
tributed Systems, vol. 20, no. 4, pp. 567-580, April 2009. 

[115] L. Zhang and Y. Guan, “TOPO: A Topology-aware Single 
Packet Attack Traceback Scheme,” in Securecomm and Work¬ 
shops. IEEE Press, September 2006, pp. 1-10. 

[116] S. Matsuda, T. Baba, A. Hayakawa, and T. Nakamura, “Design 
and Implementation of Unauthorized Access Tracing System,” 
in Proceedings of the 2002 Symposium on Applications and 
the Internet. IEEE Computer Society, 2002, pp. 74-81. 

[117] H. A. Alwis, R. C. Doss, P. S. Hewage, and M. U. Chowdhury, 
“Topology Based Packet Marking for IP Traceback,” in Proc. 
of the Australian Telecommunication Networks and Applica¬ 
tions Conference (ATNAC). University of Melbourne, 2006, 
pp. 224-228. 

[118] C. Gong and K. Sarac, “A More Practical Approach for Single- 
Packet IP Traceback using Packet Logging and Marking ,” pp. 
1310-1324, 2008. 


23 


[119] T. W. Doeppner, P. N. Klein, and A. Koyfman, “Using Router 
Stamping to Identify the Source of IP Packets,” in Proc. of the 
7th ACM CCS. ACM, 2000, pp. 184-189. 

[120] B. Al-Duwairi and M. Govindarasu, “Novel Hybrid Schemes 
Employing Packet Marking and Logging for IP Traceback,” 
IEEE Trans. Parallel Distrib. Syst., vol. 17, no. 5, pp. 403- 
418, May 2006. 

[121] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, 
F. Tchakountio, S. T. Kent, and W. T. Strayer, “Hash-based IP 
Tracehack,” ACM SIGCOMM Comput. Commun. Rev., vol. 31, 
no. 4, pp. 3-14, Aug. 2001. 

[122] D. Yan, Y. Wang, S. Su, and F. Yang, “A Precise and 
Practical IP Traceback Technique Based on Packet Marking 
and Logging.” J. Inf. Sci. Eng., vol. 28, no. 3, pp. 453^70, 
2012 . 

[123] A. Belenky and N. Ansari, “IP Traceback With Deterministic 
Packet Marking,” IEEE Communications Letters, vol. 7, no. 4, 
pp. 162-164, April 2003. 

[124] C. Gong and K. Sarac, “Toward a Practical Packet Marking 
Approach for IP Traceback,” International Journal of Network 
Security, vol. 8, no. 3, pp. 271-281, 2009. 

[125] M. T. Goodrich, “Probabilistic Packet Marking for Large-scale 
IP Traceback,” lEEE/ACM Trans. Netw., vol. 16, no. 1, pp. 15- 
24, Feb. 2008. 

[126] X.-J. Wang and X.-Y. Wang, “Topology-assisted Deterministic 
Packet Marking for IP Traceback,” The Journal of China 
Universities of Posts and Telecommunications, vol. 17, pp. 
116-121, April 2010. 

[127] K. Park and H. Lee, “On the Effectiveness of Probabilistic 
Packet Marking for IP Traceback under Denial of Service 
Attack,” pp. 338-347, 2001. 

[128] T. Baba and S. Matsuda, “Tracing Network Attacks to Their 
Sources,” IEEE Internet Computing, vol. 6, no. 2, pp. 20-26, 
Mar. 2002. 

[129] A. Mankin, D. Massey, C.-L. Wu, S. F. Wu, and L. Zhang, “On 
Design and Evaluation of ’’Intention-Driven” ICMP Trace- 
back,” in Computer Communications and Networks, 2001. 
Proceedings. Tenth International Conference on. IEEE, 2001, 
pp. 159-165. 

[130] S. Lee and C. Shields, “Challenges to Automated Attack 
Traceback,” IT Professional, vol. 4, no. 3, pp. 12-18, May 
2002 . 

[131] R. Beverly, “Spooler project: State of ip spoofing,” November 
2014. [Online]. Available: http://spoofer.cmand.org/summary. 
php 

[132] J. Postel, “Internet Protocol,” RFC 791 (Internet Standard), 
Internet Engineering Task Force, Sep. 1981, updated by 
RFCs 1349, 2474. [Online]. Available: http://www.ietf.org/ 
rfc/rfc79Ltxt 

[133] X. Lu, G. L, P. Zhu, and Y. Chen, “MASK: An Efficient 
Mechanism to Extend Inter-domain IP Spoofing Preventions,” 
pp. 1745-1760, November 2008. 

[134] G. Velmayil and S. Pannirselvam, “Detection and Removal 
of IP Spoofing through Extended-Inter Domain Packet Filter 
Architecture,” International Journal of Computer Applications, 
vol. 49, no. 17, pp. 37-43, July 2012. 

[135] F. Guo, J. Chen, and T. cker Chiueh, “Spoof Detection for 
Preventing DoS Attacks against DNS Servers,” in Proc. of 
ICDCS. IEEE, 2006. 

[136] D. Kuptsov and A. Gurtov, “SAVAH: Source Address Val¬ 
idation with Host Identity Protocol,” in Proc. of the First 
International ICST Conference on Security and Privacy in Mo¬ 
bile Information and Communication Systems (MobiSec’09. 
Springer, 2009, pp. 190-201. 


[137] A. Gurtov, Host Identity Protocol (HIP): Towards the Secure 
Mobile Internet. John Wiley & Sons, 2008, vol. 21. 

[138] R. Moskowitz and P. Nikander, “Host Identity Protocol 
(HIP) Architecture,” RFC 4423 (Informational), Internet 
Engineering Task Force, may 2006. [Online]. Available: 
http://www.ietf.org/rfc/rfc4423.txt 

[139] H. Ishibashi, N. Yamai, K. Abe, and T. Matsuura, “A Pro¬ 
tection Method Against Unauthorized Access and Address 
Spoofing for Open Network Access Systems,” in IEEE Pacific 
Rim Conference on Communications, Computers and signal 
Processing, vol. 1. IEEE, 2001, pp. 10-13. 

[140] J. M. Gonzalez, M. Anwar, and J. B. Joshi, “A Trust-based 
Approach Against IP-spoofing Attacks,” in Ninth Annual Con¬ 
ference on Privacy, Security and Trust (PST 2011). IEEE, 
July 2011, pp. 63-70. 

[141] M. O. H. Noureldien A. Noureldien, “Block Spoofed Packets 
at Source (BSPS): A Method for Detecting and Preventing 
All Types of Spoofed Source IP Packets and SYN Flooding 
Packets at Source: A Theoretical Framework,” International 
Journal of Networks and Communications, vol. 2, no. 3, pp. 
33-37, 2012. 

[142] C. Kreibich, A. Warfield, J. Crowcroft, S. Hand, and 1. Pratt, 
“Using Packet Symmetry to Curtail Malicious Traffic,” in 
Proceedings of the 4th Workshop on Hot Topics in Networks 
(Hotnets-VI), College Park, MD, USA, 2005. 

[143] T. Korkmaz, C. Gong, K. Sara, and S. G. Dykes, “Single 
Packet IP Traceback in AS-level Partial Deployment Scenario,” 
IJSN, pp. 95-108, 2007. 

[144] M. Sung, J. Xu, J. Li, and L. Li, “Large-scale IP Traceback 
in High-speed Internet: Practical Techniques and Information- 
theoretic Foundation,” lEEE/ACM Trans. Netw., vol. 16, no. 6, 
pp. 1253-1266, Dec. 2008. 

[145] K. Egevang and P. Francis, “The IP Network Address 
Translator (NAT),” RFC 1631 (Informational), Internet 
Engineering Task Force, May 1994, obsoleted by RFC 3022. 
[Online]. Available: http://www.ietf.org/rfc/rfcl63Ltxt 

[146] K. Ali, M. Zulkemine, and H. S. Hassanein, “Packet Filtering 
Based on Source Router Marking and Hop-Count,” in LCN. 
IEEE Computer Society, 2007, pp. 1061-1068. 

[147] N. Arumugam and C. Venkatesh, “A Dynamic Method to 
Detect IP Spoofing on Data Network Using Ant Algorithm,” 
lOSR Journal of Engineering (lOSRJEN), vol. 2, October 2012. 

[148] P. Ferguson and D. Senie, “Network Ingress Filtering: 
Defeating Denial of Service Attacks which employ IP Source 
Address Spoofing,” RFC 2267 (Informational), Internet 
Engineering Task Force, January 1998, obsoleted by RFC 
2827. [Online]. Available: http://www.ietf.org/rfc/rfc2267.txt 

[149] K. Butler, T. Farley, P. Mcdaniel, and J. Rexford, “A survey 
of BGP security issues and solutions,” AT&T Labs Research, 
2008. 

[150] J. Israr, M. Guennoun, and H. T. Mouftah, “Mitigating IP 
Spoofing by Validating BGP Routes Updates,” International 
Journal of Computer Science and Network Security (IJCSNS), 
vol. 9, no. 5, pp. 71-76, May 2009. 

[151] C. L. Abad and R. 1. Bonilla, “An Analysis on the Schemes 
for Detecting and Preventing ARP Cache Poisoning Attacks,” 
in 27th International Conference on Distributed Computing 
Systems Workshops. IEEE, 2007, pp. 60-60. 

[152] W. Strayer, C. Jones, F. Tchakountio, A. Snoeren, B. Schwartz, 
R. Clements, M. Condell, and C. Partridge, “Traceback of 
single IP packets using SPIE,” in DARPA Information Surviv¬ 
ability Conference and Exposition, 2003. Proceedings, vol. 2, 
April 2003, pp. 266-270. 


24 


[153] R. Shokri, A. Varshovi, H. Mohammadi, and N. Yazdani, 
“DDPM: Dynamic Deterministic Packet Marking for IP Trace- 
back” in 14th IEEE International Conference on Networks, 
vol. 2. IEEE, September 2006, pp. 1-6. 

[154] Q. Dong, M. Adler, S. Banerjee, and K. Hirata, “Efficient 
Probabilistic Packet Marking,” in 13th IEEE ICNP. IEEE, 
November 2005. 

[155] B. Duwairi, A. Chakrabarti, and G. Manimaran, “An Efficient 
Probabilistic Packet Marking Scheme for IP Traceback,” pp. 
1263-1269, November 2004. 

[156] A. Belenky and N. Ansari, “On Deterministic Packet Mark¬ 
ing,” Comput. Netw., vol. 51, no. 10, pp. 2677-2700, Jul. 2007. 

[157] Z. Chen and M.-C. Lee, “An IP Traceback Technique Against 
Denial-of-service Attacks,” in Computer Security Applications 
Conference, 2003. Proceedings. 19th Annual, Dec 2003, pp. 
96-104. 

[158] H. C. J. Lee, V. L. L. Thing, Y. Xu, and M. Ma, “ICMP 
Traceback with Cumulative Path, an Efficient Solution for 
IP Traceback,” in Proc. of Information and Communications 
Security, 5th International Conference, ICICS, vol. 2836. 
Springer, 2003, pp. 124-135. 

[159] H.-W. Lee, M.-G. Kang, and C.-W. Choi, “PTrace: Push- 
back/SVM Based ICMP Traceback Mechanism against DDoS 
Attack,” in Computational Science and Its Applications - 
ICCSA 2004, vol. 3043. Springer, 2004, pp. 302-309. 

[160] B.-T. Wang and H. Schulzrinne, “An IP Traceback Mechanism 
for Reflective DoS Attacks,” in Canadian Conference on 
Electrical and Computer Engineering, vol. 2, May 2004, pp. 
901-904. 

[161] R. Feiertag, C. Kahn, P. Porras, D. Schnackenberg, 
S. Staniford-Chen, and B. Tung, “A Common Intrusion Spec¬ 
ification Language (CISL),” 1999. 

[162] R. Atkinson, “Security Architecture for the Internet Protocol,” 
IETF, RFC 1825, August 1995. 

[163] S. Kent, “IP Authentication Header,” IETF, RFC 4302, De¬ 
cember 2005. 

[164] -, “IP Encapsulating Security Payload (ESP),” IETF, RFC 

4303, December 2005. 

[165] V. Santiraveewan and Y. Permpoontanalarp, “A Graph-based 
Methodology for Analyzing IP Spoofing Attack,” in Proc. of 
the 18th International Conference on Advanced Information 
Networking and Applications, ser. AINA ’04. IEEE Computer 
Society, 2004. 

[166] W. Wei, F. Chen, Y. Xia, and G. Jin, “A Rank Correlation 
Based Detection against Distributed Reflection DoS Attacks,” 
Communications Letters, IEEE, vol. 17, no. 1, pp. 173-175, 
January 2013. 

[167] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis, 
“Detecting DNS Amplification Attacks,” in Workshop on Crit¬ 
ical Information Infrastructures Security (CRITIS), vol. 5141. 
Springer, 2008, pp. 185-196. 

[168] S. Di Paola and D. Lombardo, “Protecting Against DNS 
Reflection Attacks with Bloom Filters,” in Proceedings of 
the 8th International Conference on Detection of Intrusions 
and Malware, and Vulnerability Assessment, ser. DIMVA’ll. 
Springer-Verlag, 2011, pp. 1-16. 

[169] H. Tsunoda, Y. Nemoto, K. Ohta, and A. Yamamoto, “A 
Simple Response Packet Confirmation Method for DRDoS 
Detection,” in Proc. of the 8th International Conference on 
Advanced Communication Technology (ICACT 2006), vol. 3. 
IEEE Press, February 2006. 

[170] H. Tsunoda, K. Ohta, A. Yamamoto, N. Ansari, Y. Waizumi, 
and Y. Nemoto, “Detecting DRDoS Attacks by a Simple Re¬ 


sponse Packet Confirmation Mechanism,” Comput. Commun., 
vol. 31, no. 14, pp. 3299-3306, Sep. 2008. 

[171] T. Peng, C. Leckie, and K. Ramamohanarao, “Protection 
from Distributed Denial of Service Attacks Using History- 
based IP Filtering,” in Communications, 2003. ICC’03. IEEE 
International Conference on, vol. 1. IEEE, 2003, pp. 482- 
486. 

[172] J. Mirkovic, G. Prier, and P. Reiher, “Attacking DDoS at the 
Source,” in Network Protocols, 2002. Proceedings. 10th IEEE 
International Conference on. IEEE, 2002, pp. 312-321. 

[173] -, “Source-end DDoS Defense,” in Second IEEE Interna¬ 

tional Symposium on Network Computing and Applications. 
NCA 2003. IEEE, 2003, pp. 171-178. 

[174] T. M. Gil and M. Poletto, “MULTOPS: A Data-structure for 
Bandwidth Attack Detection,” in USENIX Security Sympo¬ 
sium, 2001. 

[175] S. Abdelsayed, D. Glimsholt, C. Leckie, S. Ryan, and 
S. Shami, “An Efficient Filter for Denial-of-Service Bandwidth 
Attacks,” in Global Telecommunications Conference, 2003. 
GLOBECOM’03. IEEE, vol. 3. IEEE, 2003, pp. 1353-1357. 

[176] T. Peng, C. Leckie, and K. Ramamohanarao, “Detecting 
Reflector Attacks by Sharing Beliefs,” in Proc. of IEEE 
GLOBECOM, 2003, pp. 1358-1362. 

[177] Y. Kim, W. C. Lau, M. C. Chuah, and H. J. Chao, “Pack- 
etScore: A Statistics-Based Packet Filtering Scheme Against 
Distributed Denial-of-Service Attacks,” Dependable and Se¬ 
cure Computing, IEEE Transactions on, vol. 3, no. 2, pp. 141- 
155, 2006. 

[178] D. Huistra, “Detecting Reflection Attacks in DNS Flows,” in 
19th Twente Student Conference on IT, February 2013. 

[179] R. Mahajan, S. M. Bellovin, S. Floyd, J. loannidis, V. Paxson, 
and S. Shenker, “Controlling High Bandwidth Aggregates 
in the Network,” Computer Communication Review, vol. 32, 
no. 3, pp. 62-73, 2002. 

[180] D. K. Yau, J. Lui, F. Liang, and Y. Yam, “Defending Against 
Distributed Denial-of-Service Attacks with Max-Min Fair 
Server-Centric Router Throttles,” Transactions on Networking 
(TON), vol. 13, no. 1, pp. 29-42, 2005. 

[181] R. Chen and J.-M. Park, “Attack Diagnosis: Throttling 
Distributed Denial-of-Service Attacks Close to the Attack 
Sources,” in Proceedings. 14th International Conference on 
Computer Communications and Networks. IEEE, 2005, pp. 
275-280. 

[182] R. Chen, J.-M. Park, and R. Marchany, “TRACK: A Novel Ap¬ 
proach for Defending Against Distributed Denial-of-Service 
Attacks,” Technical Report TR ECEO6-02. Dept, of Electrical 
and Computer Engineering, Virginia Tech, 2006. 

[183] N. Fultz and J. Grossklags, “Blue Versus Red: Towards a 
Model of Distributed Security Attacks,” in Financial Cryp¬ 
tography and Data Security. Springer, 2009, pp. 167-183. 

[184] C. Fachkha, E. Bou-Harb, and M. Debbabi, “Towards a Fore¬ 
casting Model for Distributed Denial of Service Activities,” in 
I2th IEEE International Symposium on Network Computing 
and Applications (NCA), August 2013, pp. 110-117. 

[185] -, “Fingerprinting Internet DNS Amplification DDoS Ac¬ 

tivities,” in 6th International Conference on New Technologies, 
Mobility and Security (NTMS), March 2014, pp. 1-5. 

[186] -, “Inferring Distributed Reflection Denial of Service At¬ 

tacks from Darknet,” Computer Communications, vol. 62, pp. 
59 - 71, 2015. 

[187] S. Yu, W. Zhou, W. Jia, S. Guo, Y. Xiang, and F. Tang, “Dis¬ 
criminating DDoS Attacks from Flash Crowds Using Flow 
Correlation Coefficient,” Parallel and Distributed Systems, 
IEEE Transactions on, vol. 23, no. 6, pp. 1073-1080, 2012. 


25 



[188] C. Dietzel, A. Feldmann, and T. King, “Blackholing at IXPs: 
On the Effectiveness of DDoS Mitigation in the Wild,” in 
Proceedings of PAM 2016, ser. LCNS, T. Karagiannis and 
X. Dimitropoulos, Eds., vol. 9631. Springer, 2016, pp. 319- 
332. 

[189] J. Mirkovic, M. Robinson, and R Reiher, “Alliance Eormation 
for DDoS Defense,” in Proceedings of the 2003 workshop on 
New security paradigms. ACM, 2003, pp. 11-18. 

[190] J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos, M. Bai¬ 
ley, and M. Karir, “Taming the 800 pound gorilla: The rise 


and decline of ntp ddos attacks,” in Proceedings of the 2014 
Conference on Internet Measurement Conference. ACM, 
2014, pp. 435-448. 

[191] The Shadowserver Foundation, April 2015. [Online]. 
Available: https://dnsscan.shadowserver.org/ 

[192] The Measurement Factory, April 2015. [Online]. Available: 
http://dns.measurement-factory.com 

[193] Network Time Foundation, April 2015. [Online]. Available: 
http://openntpproject.org/ 


26 


